From vinschen at redhat.com Fri Jul 1 00:39:11 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 30 Jun 2016 16:39:11 +0200 Subject: SSH Closes Immediately After Opening In-Reply-To: <57743F25.9090704@gmail.com> References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> <57743F25.9090704@gmail.com> Message-ID: <20160630143911.GT981@calimero.vinschen.de> On Jun 29 23:35, ?ngel Gonz?lez wrote: > On 29/06/16 22:57, Wallace Forman wrote: > > I used the latest version from here: > > > > http://www.mls-software.com/opensshd.html > > > > On my other (Windows 10) machine (on which openssh works), I have cygwin > > installed, but if ssh was using cygwin, I wasn't aware of it. I just ran > > ssh from the command prompt. > > > > Wallace Forman > > Yes, that ssh server is cygwin-based. It is however including the basic > cygwin files it needs, so the fact that it actually doesn't work without a > normal cygwin install seems a bug in the package. Using the orignal Cygwin distro OpenSSH instead of some arbitrary 3rd party package fixes this. 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 wallace.forman at gmail.com Fri Jul 1 01:12:17 2016 From: wallace.forman at gmail.com (Wallace Forman) Date: Thu, 30 Jun 2016 11:12:17 -0400 Subject: SSH Closes Immediately After Opening In-Reply-To: References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> <57743F25.9090704@gmail.com> Message-ID: Embarrassing to say, I'm really not sure what constitutes a "console" or "shell". To explain what does and does not seem to be working: 1) I have two windows computers on the same wireless network, both with openssh for windows installed from the link previously sent. 2) On computer 1, sshd is running, but when connecting with "ssh localhost" from the command prompt on that same computer, sshd seems to be accepting the password, but closing immediately (see output in previous messages). 3) On computer 2, sshd runs, and I can connect on that computer from the command prompt or from putty. 4) When I try to connect from computer 2 to computer 1 (from putty or command prompt), the session closes immediately, as when I try to connect from Computer 1. 5) Also, Computer 2 does not seem to be accepting the password input from computer 1. Haven't really tried to troubleshoot this yet, perhaps this is an sshd_config issue. Wallace Forman 913-669-4453 On Wed, Jun 29, 2016 at 11:23 PM, Hisashi T Fujinaka wrote: > On Wed, 29 Jun 2016, ?ngel Gonz?lez wrote: > > On 29/06/16 22:57, Wallace Forman wrote: >> >>> I used the latest version from here: >>> >>> http://www.mls-software.com/opensshd.html >>> >>> On my other (Windows 10) machine (on which openssh works), I have cygwin >>> installed, but if ssh was using cygwin, I wasn't aware of it. I just ran >>> ssh from the command prompt. >>> >>> Wallace Forman >>> >> >> Yes, that ssh server is cygwin-based. It is however including the basic >> cygwin files it needs, so the fact that it actually doesn't work without a >> normal cygwin install seems a bug in the package. >> > > I wasn't really paying attention but the first thing I thought of was > this sounds like the problem I usually see when my shell is broken. Can > you log into the account using the console? > > -- > Hisashi T Fujinaka - htodd at twofifty.com > BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee > From keisial at gmail.com Fri Jul 1 07:45:18 2016 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Thu, 30 Jun 2016 23:45:18 +0200 Subject: SSH Closes Immediately After Opening In-Reply-To: References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> <57743F25.9090704@gmail.com> Message-ID: <577592EE.6030307@gmail.com> On 30/06/16 17:12, Wallace Forman wrote: > Embarrassing to say, I'm really not sure what constitutes a "console" > or "shell". The shell is the program that reads the commands you write and executes them. ssh doesn't run "cd" It handles the secure layer, launches your shell and leaves you to communicate with it however you want. So for instance if your shell is cmd.exe you would list the contents of a folder with "dir", but use "ls" in bash. If after authentication sshd is not able to run your shell (errors reading the user profile, the shell is not executable, etc.), then it closes the connection, as you report. > To explain what does and does not seem to be working: > (?) > > 2) On computer 1, sshd is running, but when connecting with "ssh > localhost" from the command prompt on that same computer, sshd seems > to be accepting the password, but closing immediately (see output in > previous messages). You can verify whether it is really accepting the password by entering a wrong one. > > 4) When I try to connect from computer 2 to computer 1 (from putty or > command prompt), the session closes immediately, as when I try to > connect from Computer 1. This is the same as #2 Regards From jweisblat at yahoo-inc.com Fri Jul 1 10:56:35 2016 From: jweisblat at yahoo-inc.com (jweisblat at yahoo-inc.com) Date: Fri, 1 Jul 2016 00:56:35 +0000 (UTC) Subject: Removing PKCS#11 card from SSH Agent with ssh-add References: <2057167045.1672218.1467334595711.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <2057167045.1672218.1467334595711.JavaMail.yahoo@mail.yahoo.com> Hello, Several of my coworkers and I, as well as others, have been confused by the behavior of?ssh-add -D. From the man page: ? ? ?-D ? ? ?Deletes all identities from the agent. The current behavior of?ssh-add -D?is to send?SSH2_AGENTC_REMOVE_ALL_IDENTITIES?and?SSH_AGENTC_REMOVE_ALL_RSA_IDENTITIES?to the agent, removing all the keys from the agent, including any keys added via PKCS#11 libraries. However, the PKCS#11 library is still loaded in the agent, and it won't be unloaded (and thus fails to be reloaded, with an unhelpful error) unless?SSH_AGENTC_REMOVE_SMARTCARD_KEY?is sent, and that takes a parameter of the specific?PKCS#11?library involved. Is this behavior the intended behavior of?ssh-add -D? If it is, we'd be happy to introduce a patch to improve the error message to suggest trying to remove it first. If not, I can imagine several solutions, which we'd be happy to implement, depending on which the community thinks is best: ?- change the behavior of the agent to remove the smartcard in addition to the corresponding identity when?SSH2_AGENTC_REMOVE_ALL_IDENTITIES?is run. This is somewhat inideal in the case of that identity being used with protocol version 1.?- add a new agent command?SSH_AGENTC_REMOVE_ALL_SMARTCARD_KEYS?in addition to?SSH_AGENTC_REMOVE_SMARTCARD_KEY?that removes all smartcard keys, modify the agent to accept it and modify?ssh-add?to send it in addition to the other 2 commands on?ssh -D. Here is a demonstration of current behavior: [~]$?ssh-add -lThe agent has no identities.[~]$?ssh-add -s /usr/local/lib/libykcs11.dylibEnter passphrase for PKCS#11:Card added: /usr/local/lib/libykcs11.dylib[~]$?ssh-add -l2048 SHA256:cJUGM7tTnFD9a0BpI936ERA3Ay+/MFu3huzB+APPoZs /usr/local/lib/libykcs11.dylib (RSA)[~]$?ssh-add -DAll identities removed.[~]$?ssh-add -lThe agent has no identities.[~]$ ssh-add -s /usr/local/lib/libykcs11.dylib # Add the card back into the agent, it wasn't unloaded by?Enter passphrase for PKCS#11:Could not add card "/usr/local/lib/libykcs11.dylib": agent refused operation[~]$ ssh-add -lThe agent has no identities.[~]$ ssh-add -e /usr/local/lib/libykcs11.dylibCard removed: /usr/local/lib/libykcs11.dylib[~]$ ssh-add -lThe agent has no identities.[~]$ ssh-add -s /usr/local/lib/libykcs11.dylibEnter passphrase for PKCS#11:Card added: /usr/local/lib/libykcs11.dylib[~]$ ssh-add -l2048 SHA256:cJUGM7tTnFD9a0BpI936ERA3Ay+/MFu3huzB+APPoZs /usr/local/lib/libykcs11.dylib (RSA)[~]$ Sincerely, Jakob WeisblatParanoid LabsYahoo! Inc From vijaysridhar03 at gmail.com Fri Jul 1 19:27:32 2016 From: vijaysridhar03 at gmail.com (Vijay Sridhar) Date: Fri, 1 Jul 2016 14:57:32 +0530 Subject: Not able to authenticate Windows AD Users after openssh upgrade Message-ID: Hi, We have RHEL6 in our enviroment , , our openssh version 5.3 & we were able to connect windows Active directory users using ldap & nslcd configuration ( /etc/pam_ldap.conf , nsswitch.conf ) . Recently we upgraded to openssh 7.2 , we compile openssh with Pam ,Md5password , kerbose5 , but after upgradation we were not able to connect AD users ( ldap users) , only we were able to connect Local users . Key based authentication is working for both Local & Remote users , but still we were unable to find the solution , kindly advice if any thing which i am missing in openssh or any additional configuration required -- Regards ????? ??????? S.Vijay 93827-01883 From wallace.forman at gmail.com Sat Jul 2 02:18:14 2016 From: wallace.forman at gmail.com (Wallace Forman) Date: Fri, 1 Jul 2016 12:18:14 -0400 Subject: SSH Closes Immediately After Opening In-Reply-To: <577592EE.6030307@gmail.com> References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> <57743F25.9090704@gmail.com> <577592EE.6030307@gmail.com> Message-ID: Thanks all for the responses. I was able to get ssh working with cygwin. Wallace Forman 913-669-4453 On Thu, Jun 30, 2016 at 5:45 PM, ?ngel Gonz?lez wrote: > On 30/06/16 17:12, Wallace Forman wrote: > > Embarrassing to say, I'm really not sure what constitutes a "console" or > "shell". > > > The shell is the program that reads the commands you write and executes > them. > ssh doesn't run "cd" It handles the secure layer, launches your shell and > leaves you to communicate with it however you want. So for instance if your > shell is cmd.exe you would list the contents of a folder with "dir", but > use "ls" in bash. > > If after authentication sshd is not able to run your shell (errors reading > the user profile, the shell is not executable, etc.), then it closes the > connection, as you report. > > To explain what does and does not seem to be working: > (?) > > 2) On computer 1, sshd is running, but when connecting with "ssh > localhost" from the command prompt on that same computer, sshd seems to be > accepting the password, but closing immediately (see output in previous > messages). > > You can verify whether it is really accepting the password by entering a > wrong one. > > > 4) When I try to connect from computer 2 to computer 1 (from putty or > command prompt), the session closes immediately, as when I try to connect > from Computer 1. > > This is the same as #2 > > > Regards > From openssh at mzpqnxow.com Sat Jul 2 16:03:08 2016 From: openssh at mzpqnxow.com (AG) Date: Sat, 2 Jul 2016 02:03:08 -0400 Subject: Two patches in Bugzilla (MaxDisplays, wildcard PermitOpen hostname) for inclusion upstream Message-ID: Greetings, I just wanted to point out that I've submitted two patches complete with documentation for some very basic but (IMO) reasonable and necessary features. I'd like to have these considered for inclusion in the next OpenSSH release. -- Configurable MAX_DISPLAYS value via MaxDisplays https://bugzilla.mindrot.org/show_bug.cgi?id=2580 -- This patch allows the #define MAX_DISPLAYS value to be controlled via an sshd_config directive, aptly named 'MaxDisplays'. This is useful when using OpenSSH as a multi-factor gateway to forward X11 sessions through a centralized host, specifically when there are several thousand users, beyond the default max value of 1000. With this patch, the default value of 1000 is used unless explicitly set to another value in sshd_config -- PermitOpen hostname wildcard https://bugzilla.mindrot.org/show_bug.cgi?id=2582 -- This simple patch allows for a wildcard symbol to be used as the hostname in an sshd_config PermitOpen directive. This is useful when using OpenSSH as a multi-factor gateway to forward access to a specific service on a large and effectively undefined list of hosts "behind" the multi-factor gateway. For example: PermitOpen *:3389 This would allow an OpenSSH daemon to act as an RDP gateway when it is impractical to list each and every host you would like to allow RDP forwards to. The use case here is a network with > 1000 machines. This patch very intentionally keeps it simple- the asterisk is not a pattern match, it is just a symbol that means 'any host'. There is no *.domain.com type logic. I'm happy to take any feedback on these patches. I've spoken with Red Hat engineers and they have built test RPMs for them for my environment, but they will not officially accept them unless upstream OpenSSH accepts them into a release. Thanks, I appreciate the consideration. If anyone has any questions about the value and use cases for these patches, please feel free to let me know on or off list. AG From badingb at us.ibm.com Mon Jul 4 12:19:43 2016 From: badingb at us.ibm.com (Bruce F Bading) Date: Sun, 3 Jul 2016 21:19:43 -0500 Subject: SSH multi factor authentication Message-ID: There has been some good discussion around our IBM security team as to what actually constitutes SSH multi factor authentication. There are 2 options being discussed. One, the Google Authenticator (OTP authentication). Two, Public/Private key authentication (pubkeyauthentication = yes) which supports pass phrase private key authentication. Which of these is considered multi-factor authentication and can you give a brief response? There are different opinions here and your opinion is greatly appreciated. Sincerely, Bruce F. Bading Senior Security Consultant IBM Systems and Technology Group 830-237-6851 badingb at us.ibm.com member ISACA since 1985 "United We Stand" For those with risk, your time to remediate is today. For those who have been breached, your time to remediate was yesterday! From lists at spuddy.org Mon Jul 4 12:53:37 2016 From: lists at spuddy.org (Stephen Harris) Date: Sun, 3 Jul 2016 22:53:37 -0400 Subject: SSH multi factor authentication In-Reply-To: References: Message-ID: <20160704025337.GA3204@mercury7.spuddy.org> On Sun, Jul 03, 2016 at 09:19:43PM -0500, Bruce F Bading wrote: > One, the Google Authenticator (OTP authentication). On its own, this is not 2FA. It's single factor ("something you have"). A combination of Google Authenticator _and_ password is 2FA. This is easy to do with PAM. > Two, Public/Private key authentication (pubkeyauthentication = yes) which > supports pass phrase private key authentication. This is 2FA in that you need the private key and the passphrase for it. Unfortunately this can't be enforced at the server; it's client side. That's because the client could _remove_ the passphrase and reduce it to "something you have". The server can't tell the difference. So, from a controls perspective, you have to assume "single factor". -- rgds Stephen From djm at mindrot.org Mon Jul 4 16:04:23 2016 From: djm at mindrot.org (Damien Miller) Date: Mon, 4 Jul 2016 16:04:23 +1000 (AEST) Subject: SSH multi factor authentication In-Reply-To: <20160704025337.GA3204@mercury7.spuddy.org> References: <20160704025337.GA3204@mercury7.spuddy.org> Message-ID: On Sun, 3 Jul 2016, Stephen Harris wrote: > On Sun, Jul 03, 2016 at 09:19:43PM -0500, Bruce F Bading wrote: > > One, the Google Authenticator (OTP authentication). > > On its own, this is not 2FA. It's single factor ("something you > have"). > > A combination of Google Authenticator _and_ password is 2FA. This is > easy to do with PAM. Agreed > > Two, Public/Private key authentication (pubkeyauthentication = yes) which > > supports pass phrase private key authentication. > > This is 2FA in that you need the private key and the passphrase for it. I don't agree - being able to unlock a private key is just part of "possessing" it. OTOH publickey+password authentication could be considered 2FA. Ideally with the key rendered practically uncloneable by holding it on a token, etc. -d From jon at onlineis.com Wed Jul 6 22:10:44 2016 From: jon at onlineis.com (Jon Burns) Date: Wed, 6 Jul 2016 08:10:44 -0400 Subject: Where to Get OpenSSH 7.2p2-3? Message-ID: <030601d1d77f$6c50fb40$44f2f1c0$@onlineis.com> I can download and install 7.2p2 for Ubuntu Linux, but there does not seem to be a way to upgrade to 7.2p2-3. Please advise. Thanks, Jon From borut.hadzialic at gmail.com Wed Jul 6 18:19:49 2016 From: borut.hadzialic at gmail.com (=?UTF-8?Q?Borut_Had=C5=BEiali=C4=87?=) Date: Wed, 6 Jul 2016 01:19:49 -0700 (PDT) Subject: configure in 7.1p1 fails on Solaris 10 SPARC In-Reply-To: References: Message-ID: Hello, it might be that you compiled and installed 64-bit openssl libraries, but are doing a 32-bit openssh build. In this case your 64-bit openssl libraries are 'not found' (although they are in correct place, and the '--with-ssl-dir' is correctly set), and the openssh Configure scripts falls back to the old/unwanted 32-bit openssl libraries in /usr/sfw/lib This worked for me (on SunOS 5.10 Generic_150401-22 i86pc i386 i86pc Solaris, with gcc (GCC) 3.4.3 ) 1. Configure for openssl x at y:~/build/openssl-1.0.1s > ./Configure solaris-x86-gcc --prefix=/some/path/openssl-1.0.1s --openssldir=/some/path/openssl-1.0.1s/openssl shared (solaris-x86-gcc configures for a 32-bit build. I had to use './Configure' because './config' was throwing errors when solaris-x86-gcc was specified) make, make install, etc.. 2. Configure for openssh-7.2p2: x at y:~/build/openssh-7.2p2 >./configure --prefix /some/path/openssh-7.2p2 --with-ssl-dir=/some/path/openssl-1.0.1s --with-md5-passwords --your-other-options .... No other configuration was needed (LDFLAGS, LD_LIBRARY_PATH, CPPFLAGS, etc..) On Monday, 31 August 2015 17:12:21 UTC+2, Bernt Jernberg wrote: > > Hi, > > I am trying to build the 7.1p1 on Solaris 10 SPARC. > I have build OpenSSL 1.0.1p and installed it in /opt/local/openssl. > Configure options for that: > > export > PATH=/opt/local/bin:/usr/sfw/bin:/usr/ccs/bin:/usr/bin:/usr/sbin:/sbin > export MAKE=gmake > ./Configure shared solaris64-sparcv9-gcc -R/usr/sfw/lib/sparcv9 > -R/opt/local/openssl/lib --prefix=/opt/local/openssl > gmake test > gmake install > > export > PATH=/opt/local/bin:/usr/sfw/bin:/usr/ccs/bin:/usr/bin:/usr/sbin:/sbin > ./configure --sysconfdir=/etc/opt/openssh \ > --prefix=/opt/local \ > --with-solaris-contracts \ > --with-tcp-wrappers=/usr/sfw/lib \ > --with-ssl-dir=/opt/local/openssl \ > --with-audit=bsm \ > --without-bsd-auth \ > --with-zlib=/usr/sfw/lib \ > --with-privsep-path=/var/opt/empty \ > --with-pam \ > --with-privsep-user=sshd \ > --with-default-path=/opt/local/bin:/usr/bin:/usr/sbin:/sbin \ > > --with-superuser-path=/opt/local/sbin:/opt/local/bin:/sbin:/usr/sbin:/usr/bin > > \ > --with-kerberos5=/opt/local > CPPFLAGS='-I/opt/local/openssl/include' LDFLAGS='-L/opt/local/openssl/lib' > > # crle > > Configuration file [version 4]: /var/ld/ld.config > Default Library Path (ELF): > /opt/local/openssl/lib:/lib:/usr/lib:/usr/ccs/lib:/usr/sfw/lib > Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system > default) > > Command line: > crle -c /var/ld/ld.config -l > /opt/local/openssl/lib:/lib:/usr/lib:/usr/ccs/lib:/usr/sfw/lib > > > I am using the default compiler: > > # /usr/sfw/bin/gcc --version > gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > # uname -a > SunOS myhost 5.10 Generic_142900-11 sun4u sparc SUNW,Sun-Fire-V215 > > No matter what I do the configure fails with: > > checking OpenSSL header version... 1000110f (OpenSSL 1.0.1p 9 Jul 2015) > checking OpenSSL library version... configure: error: OpenSSL >= 0.9.8f > required (have "0090704f (OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes > for: > CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 > CVE-2006-4343 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590))") > > It always checks the one installed in /usr/sfw/lib > > Am I missing something obvious? > > Bernt Jernberg > _______________________________________________ > openssh-unix-dev mailing list > openssh-... at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cjwatson at debian.org Thu Jul 7 03:55:46 2016 From: cjwatson at debian.org (Colin Watson) Date: Wed, 6 Jul 2016 18:55:46 +0100 Subject: Where to Get OpenSSH 7.2p2-3? In-Reply-To: <030601d1d77f$6c50fb40$44f2f1c0$@onlineis.com> References: <030601d1d77f$6c50fb40$44f2f1c0$@onlineis.com> Message-ID: <20160706175546.GA25131@riva.ucam.org> On Wed, Jul 06, 2016 at 08:10:44AM -0400, Jon Burns wrote: > I can download and install 7.2p2 for Ubuntu Linux, but there does not seem > to be a way to upgrade to 7.2p2-3. Please advise. What version of Ubuntu are you using? -3 is a packaging revision, not something you should ask the upstream development list about, anyway. ubuntu-users at lists.ubuntu.com would be a better place to ask this kind of question, with some more details. -- Colin Watson [cjwatson at debian.org] From keisial at gmail.com Thu Jul 7 07:04:31 2016 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 06 Jul 2016 23:04:31 +0200 Subject: UsePAM documentation clarification in sshd_config. In-Reply-To: References: Message-ID: <577D725F.8080706@gmail.com> On 19/06/16 23:14, Peter Bisroev wrote: > These configuration changes do result in the expected line from > auth-pam.c in the logs. So if my understanding of this behavior is > correct, would it be beneficial for other users to document that > behavior in sshd_config and the associated man page for option UsePAM? > Maybe remove the bypass of "PermitRootLogin without-password" > statement in order to avoid confusion? > > It would also be helpful to mention the specific error line that can > appear in the logs in order to explain to the user that the problem is > not with OpenSSH itself but with the PAM configuration. > > Of course if I am missing something and my assumptions are incorrect, > under what circumstances can the behavior describe in sshd_config > manifest itself? Should a sample PAM configuration that can lead to > such behavior be documented? > > What are your thoughts? Hello Peter Thanks for your analysis. You are probably right in that it is no longer possible, in which case that comment should be changed. As for mentioning the specific error message, I would rather change the generated line, ie. index 451de78..3c410d2 100644 --- a/auth-pam.c +++ b/auth-pam.c @@ -766,12 +766,14 @@ sshpam_query(void *ctx, char **name, char **info, **prompts = NULL; } if (type == PAM_SUCCESS) { - if (!sshpam_authctxt->valid || - (sshpam_authctxt->pw->pw_uid == 0 && - options.permit_root_login != PERMIT_YES)) + if (!sshpam_authctxt->valid) fatal("Internal error: PAM auth " "succeeded when it should have " "failed"); + if (sshpam_authctxt->pw->pw_uid == 0 && + options.permit_root_login != PERMIT_YES) + fatal("PAM auth succeeded for root " + "but PermitRootLogin is not enabled"); import_environments(&buffer); *num = 0; **echo_on = 0; In case someone else wants to misconfigure his system to test this: /etc/ssh/sshd_config: PermitRootLogin no PasswordAuthentication no ChallengeResponseAuthentication yes /etc/pam.d/sshd: auth [default=ignore success=1] pam_succeed_if.so uid != 0 auth sufficient pam_permit.so $ ssh -oPasswordAuthentication=no -oChallengeResponseAuthentication=yes root at localhost Regards From badingb at us.ibm.com Fri Jul 8 00:00:28 2016 From: badingb at us.ibm.com (Bruce F Bading) Date: Thu, 7 Jul 2016 09:00:28 -0500 Subject: SSH multi factor authentication In-Reply-To: References: <20160704025337.GA3204@mercury7.spuddy.org> Message-ID: Hi Gentlemen, Thank you both for your valued opinion. I do however agree that public key authentication cannot be fully considered MFA as have 2 PCI QSAs I have spoken with. This is because it is not enforceable server side. Many things can affect client side security. It is distributable and not enforceable at a single point. The key can be regenerated or downloaded again and regenerated to remove the paraphrase making it single factor authentication. Keystoke loggers can log the keystrokes to unlock the key and capture it in band on the client. RSA and OTP generated by google authenticator w/password authentication can occur out of band and since enforceable on the server side are much more difficult to breach. Again, I want to thank you both for your valued opinion and which everyone a very great day. Sincerely, Bruce F. Bading Senior Security Consultant IBM Systems and Technology Group 830-237-6851 badingb at us.ibm.com member ISACA since 1985 "United We Stand" For those with risk, your time to remediate is today. For those who have been breached, your time to remediate was yesterday! From: Damien Miller To: Stephen Harris Cc: Bruce F Bading/Austin/IBM at IBMUS, openssh-unix-dev at mindrot.org Date: 07/04/2016 01:04 AM Subject: Re: SSH multi factor authentication On Sun, 3 Jul 2016, Stephen Harris wrote: > On Sun, Jul 03, 2016 at 09:19:43PM -0500, Bruce F Bading wrote: > > One, the Google Authenticator (OTP authentication). > > On its own, this is not 2FA. It's single factor ("something you > have"). > > A combination of Google Authenticator _and_ password is 2FA. This is > easy to do with PAM. Agreed > > Two, Public/Private key authentication (pubkeyauthentication = yes) which > > supports pass phrase private key authentication. > > This is 2FA in that you need the private key and the passphrase for it. I don't agree - being able to unlock a private key is just part of "possessing" it. OTOH publickey+password authentication could be considered 2FA. Ideally with the key rendered practically uncloneable by holding it on a token, etc. -d From eb at emlix.com Fri Jul 8 00:04:33 2016 From: eb at emlix.com (Rolf Eike Beer) Date: Thu, 07 Jul 2016 16:04:33 +0200 Subject: [PATCH] use autoconf MKDIR_P to reduce usage of legacy mkinstalldirs script Message-ID: <6093168.hIrvdjLivQ@devpool21> Basically all platforms have a proper "mkdir -p". Autoconf has install-sh as fallback when using AC_PROG_MKDIR_P, which is also hardened against races if it is recent enough. Update that script and use MKDIR_P whereever possible. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 G?ttingen, Germany Sitz der Gesellschaft: G?ttingen, Amtsgericht G?ttingen HR B 3160 Geschaeftsfuehrung: Heike Jordan, Dr. Uwe Kracke ? Ust-IdNr.: DE 205 198 055 emlix ? smart embedded open source -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-use-AC_PROG_MKDIR_P-to-get-mkdir-p-or-substitute.patch Type: text/x-patch Size: 27123 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: This is a digitally signed message part. URL: From eb at emlix.com Fri Jul 8 00:11:29 2016 From: eb at emlix.com (Rolf Eike Beer) Date: Thu, 07 Jul 2016 16:11:29 +0200 Subject: [PATCH] apply the struct dirent penalty only when needed Message-ID: <2253677.3HDZeYoXnt@devpool21> (resend, looks like I missed the confirmation mail on first attempt) Hi, attached is a patch that reduces the memory in use on all systems where BROKEN_ONE_BYTE_DIRENT_D_NAME is not defined. It would be good if there was a ac_something variable that could be given to configure to tell it if this workaround is needed or not when cross compiling. We currently do it another way after running configure: ==== cat >>conftest.c < #include #include int main() { struct dirent d; static_assert(sizeof(d.d_name) > sizeof(char), "struct to small"); return 0; } EOF ${target_platform}-gcc ${optflags} conftest.c && \ sed -ri 's/#define (BROKEN_ONE_BYTE_DIRENT_D_NAME) 1/#undef \1/' config.h ==== Of course that only works when one has a compiler that is new enough (what we can guarantee). Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 G?ttingen, Germany Sitz der Gesellschaft: G?ttingen, Amtsgericht G?ttingen HR B 3160 Geschaeftsfuehrung: Heike Jordan, Dr. Uwe Kracke ? Ust-IdNr.: DE 205 198 055 emlix ? smart embedded open source -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-apply-the-struct-dirent-penalty-only-when-needed.patch Type: text/x-patch Size: 1383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: This is a digitally signed message part. URL: From nick at holland-consulting.net Thu Jul 7 15:07:15 2016 From: nick at holland-consulting.net (Nick Holland) Date: Thu, 7 Jul 2016 15:07:15 -0400.4333333333333371 Subject: portable sftp oddity: sftp, redirection of stderr and ControPersist Message-ID: <577EA897.30701@holland-consulting.net> hi, Ran into a problem which I thought was an AIXism, but have since found that it can be reproduced on Linux and MacOS. It can NOT be reproduced on OpenBSD. Reproduced on: AIXv7.1 OpenSSH v6.0p1 RedHat 6.8 OpenSSH 5.4p1 Redhat 7.2 OpenSSH 6.6.1p1 MacOS 10.11 (sorry, forgot to grab the OpenSSH version) Could not reproduce on: OpenBSD 5.9-current, march snapshot, OpenSSH_7.2 OpenBSD 5.3-current, April snapshot, OpenSSH_6.2 Demonstration: set up an account on a system that can ssh to itself and authenticate via keys. Create and run this script: ===== #!/usr/bin/ksh mkdir -p ~/dest for X in 1 2 3 4 5 6 7 8 9 10; do echo $X echo "cd dest put $0" | sftp -b - localhost 2>&1 | tee -a outfile done ===== Change first line to whatever shell your system uses (that's AIX's default), otherwise, should be pretty portable. Run it, it should copy itself to a directory in your home directory ten times, should take just a few seconds. Now, add the following to ~/.ssh/config : ===== ControlMaster auto ControlPath ~/.ssh/control/%h:%r:%p ControlPersist 10s ===== re-run script. * What I think should happen is the persistent control channel should greatly reduce the SSH connection time, so it should run significantly faster. * What DOES happen on platforms with a problem: the "ControlPersist" value becomes an SSH rate limiter -- instead of holding a connection OPEN for ten seconds, it PREVENTS another SSH session from starting for ten seconds! So, instead of taking maybe four seconds before, now it takes 104 seconds (10 x 10 seconds + ssh connection overhead). Change the ControlPersist to some other value, the overall speed goes up or down, but never as fast as without the ControlPersist options in place. here's where it gets weird. Remove the "2>&1" from the sftp line, and the problem goes away -- the script runs much faster with the .ssh/config file than without it. Unfortunately, I need the stderr output. :-/ It appears to be the "2>&1 | {cmd}" structure that is at fault -- doesn't matter if {cmd} is tee, wc, or a shell function (as it was in my "real" project). I have found that 2>error.file |tee outfile works, and then I can append the error.file output into the end of the "outfile" and accomplish my goals, but that's kinda ugly. Thanks for looking! Nick. From nkadel at gmail.com Sat Jul 9 21:48:19 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 9 Jul 2016 07:48:19 -0400 Subject: SSH multi factor authentication In-Reply-To: References: <20160704025337.GA3204@mercury7.spuddy.org> Message-ID: On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading wrote: > > Hi Gentlemen, > > Thank you both for your valued opinion. I do however agree that public key > authentication cannot be fully considered MFA as have 2 PCI QSAs I have > spoken with. This is because it is not enforceable server side. Many > things can affect client side security. > > It is distributable and not enforceable at a single point. > The key can be regenerated or downloaded again and regenerated to remove > the paraphrase making it single factor authentication. It's not merely possible. It's popular, and nearly inevitable. And unless you can enforce use of a designated public key on the server side, for example by breaking ownership checks and making the file and directories owned by root with user groupo access, or by auto-replacing $HOME/.ssh/authorized_keys, well, the user can replace the key at whim with their own insecure key. And most users *will* follow the default ssh-keygen behavior and use no passphrase whatsoever. That's been a problem since.... 1995, when SSH-1 was first written by Tatu Ylonen. I'd still like to see "ssh-keygen" require a command line flag to allow blank passwords, instead of the current default behavior. But when I've suggested it among users, they've explained their firm rejection of it in impolite terms. > Keystoke loggers can log the keystrokes to unlock the key and capture it in > band on the client. > RSA and OTP generated by google authenticator w/password authentication can > occur out of band and since enforceable on the server side are much more > difficult to breach. > > Again, I want to thank you both for your valued opinion and which everyone > a very great day. > > Sincerely, > Bruce F. Bading > Senior Security Consultant > > IBM Systems and Technology Group > 830-237-6851 > badingb at us.ibm.com > member ISACA since 1985 > > > "United We Stand" > > For those with risk, your time to remediate is today. > For those who have been breached, your time to remediate was yesterday! > > > > From: Damien Miller > To: Stephen Harris > Cc: Bruce F Bading/Austin/IBM at IBMUS, openssh-unix-dev at mindrot.org > Date: 07/04/2016 01:04 AM > Subject: Re: SSH multi factor authentication > > > > On Sun, 3 Jul 2016, Stephen Harris wrote: > >> On Sun, Jul 03, 2016 at 09:19:43PM -0500, Bruce F Bading wrote: >> > One, the Google Authenticator (OTP authentication). >> >> On its own, this is not 2FA. It's single factor ("something you >> have"). >> >> A combination of Google Authenticator _and_ password is 2FA. This is >> easy to do with PAM. > > Agreed > >> > Two, Public/Private key authentication (pubkeyauthentication = yes) > which >> > supports pass phrase private key authentication. >> >> This is 2FA in that you need the private key and the passphrase for it. > > I don't agree - being able to unlock a private key is just part of > "possessing" it. > > OTOH publickey+password authentication could be considered 2FA. Ideally > with the key rendered practically uncloneable by holding it on a token, > etc. > > -d > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at eviladmin.org Sun Jul 10 00:30:57 2016 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 09 Jul 2016 09:30:57 -0500 Subject: SSH multi factor authentication In-Reply-To: References: <20160704025337.GA3204@mercury7.spuddy.org> Message-ID: <57810AA1.4040605@eviladmin.org> Nico Kadel-Garcia wrote: > On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading wrote: >> Hi Gentlemen, >> >> Thank you both for your valued opinion. I do however agree that public key >> authentication cannot be fully considered MFA as have 2 PCI QSAs I have >> spoken with. This is because it is not enforceable server side. Many >> things can affect client side security. >> >> It is distributable and not enforceable at a single point. >> The key can be regenerated or downloaded again and regenerated to remove >> the paraphrase making it single factor authentication. > > It's not merely possible. It's popular, and nearly inevitable. And > unless you can enforce use of a designated public key on the server > side, for example by breaking ownership checks and making the file and > directories owned by root with user groupo access, or by > auto-replacing $HOME/.ssh/authorized_keys, well, the user can replace > the key at whim with their own insecure key. You'd do this by either moving the authorized_keys to another a root owned location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile /etc/ssh/keys/authorized_keys.%u). Or you use "AuthorizedKeysCommand" and put the keys into a "database" to reference them via a simple root-owned program. Personally I'd use the AuthorizedKeysCommand for this setup as it would provide for a better programmatic way of managing keys. - Ben From nkadel at gmail.com Sun Jul 10 00:47:34 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 9 Jul 2016 10:47:34 -0400 Subject: SSH multi factor authentication In-Reply-To: <57810AA1.4040605@eviladmin.org> References: <20160704025337.GA3204@mercury7.spuddy.org> <57810AA1.4040605@eviladmin.org> Message-ID: On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom wrote: > You'd do this by either moving the authorized_keys to another a root owned > location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile > /etc/ssh/keys/authorized_keys.%u). Or you use "AuthorizedKeysCommand" and > put the keys into a "database" to reference them via a simple root-owned > program. Yeah, that's doable. It's very rare, though. Many people prefer not to touch the default sshd_config if they can avoid it. And maintaining those keys as the root user to lock these credentials may not be work most admins want to take on. > Personally I'd use the AuthorizedKeysCommand for this setup as it would > provide for a better programmatic way of managing keys. > > - Ben Then you have to write, or activate and maintain, yet another tool. Feasible, but not many folks consider it worth the work. I've *done* things like that, way back with some "one-time password" tools I used back in the remote 9600 baud modem era. From mouring at eviladmin.org Sun Jul 10 02:00:24 2016 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 09 Jul 2016 11:00:24 -0500 Subject: SSH multi factor authentication In-Reply-To: References: <20160704025337.GA3204@mercury7.spuddy.org> <57810AA1.4040605@eviladmin.org> Message-ID: <57811F98.5010805@eviladmin.org> Nico Kadel-Garcia wrote: > On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom wrote: > >> You'd do this by either moving the authorized_keys to another a root owned >> location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile >> /etc/ssh/keys/authorized_keys.%u). Or you use "AuthorizedKeysCommand" and >> put the keys into a "database" to reference them via a simple root-owned >> program. > > Yeah, that's doable. It's very rare, though. Many people prefer not to > touch the default sshd_config if they can avoid it. Many of us prefer not to mess with PAM, Systemd, apache, and other configuration files, and would love to just install the system and use it without having to lift a finger to ever configure it. But sadly, life doesn't permit us all that luxury. So it is a poor argument. Besides, anyone maintaining a decent amount of machines not using puppet, salt, ansible, or is doing themselves and their company a disservice. > And maintaining > those keys as the root user to lock these credentials may not be work > most admins want to take on. My response was to your comment "And unless you can enforce use of a designated public key on the server side, for example by breaking ownership checks and making the file and directories owned by root with user groupo access, or by auto-replacing $HOME/.ssh/authorized_keys, well, the user can replace the key at whim with their own insecure key." So if the admin doesn't care about the restrictions you stated. Then they don't have to change the sshd_config. However, if they do then they are stepping out from the defaults. Just like how those that want chroot sftp enabled need to step out from the defaults. Just like those that need root access via authorizes keys need to step out from the defaults. >> Personally I'd use the AuthorizedKeysCommand for this setup as it would >> provide for a better programmatic way of managing keys. >> >> - Ben > > Then you have to write, or activate and maintain, yet another tool. > Feasible, but not many folks consider it worth the work. I've *done* > things like that, way back with some "one-time password" tools I used > back in the remote 9600 baud modem era. We've all written horrible stuff to satisfy business requirements. Our universe, as admins, is scattered with many "yet another tool" or "yet another set of packages" to maintain for security or for our users to do their jobs. So if the above is a requirement for your fictional admin then a tool will need to be written. And OpenSSH has already provided the means today by which it can easily integrate in. However, I would hope that it is a well written tool, and it can be shared with the community so it doesn't become a one-off burden. Anyways, the question still boils down to is Google Authenticator + Authorized Keys (with or without password) 2FA. And honestly I'm going to have to state it is 2FA in both cases. The argument is simple. If I use a password management tool (that requires me to unlock it with a different password) that auto fills in my Blizzard Battle.net login/password then I use the Blizzard's authenticator and type in the random code do I have 2FA? Clearly, I've not typed my password. I may NOT EVEN KNOW my password (which is true in this case as it is a nasty auto-generated beast =). So it is basically the same as the 2048bit RSA authorized key I use in SSH. I use a password to decrypt access, but I only really possess both as I don't have them memorized. To complete the comparison I can write myself a password manager that doesn't require me to unlock (e.g. most "remember my password" crap in browsers). So the fact it is if my password is protected or not doesn't change my knowledge (or lack of) of the password. The same goes for RSA keys. Someone can steal my password manager, hack it, and gain access. Just like they could steal steal my RSA keys off my laptop. Ben From nkadel at gmail.com Sun Jul 10 09:11:23 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 9 Jul 2016 19:11:23 -0400 Subject: SSH multi factor authentication In-Reply-To: <57811F98.5010805@eviladmin.org> References: <20160704025337.GA3204@mercury7.spuddy.org> <57810AA1.4040605@eviladmin.org> <57811F98.5010805@eviladmin.org> Message-ID: On Sat, Jul 9, 2016 at 12:00 PM, Ben Lindstrom wrote: > We've all written horrible stuff to satisfy business requirements. Our > universe, as admins, > is scattered with many "yet another tool" or "yet another set of packages" > to maintain for > security or for our users to do their jobs. Ben, I'm not trying to say it's not wise and sensible to go write a non-standard, unsupported, and potentially root access destabilizing non-standard workaround to shove user keys in a separate, locked, down, root owned repository managed by someone other than the individual user. Actually, come to to think of it, I am saying it's an idea that many admins do reject and should reject.. It's easy to do at first glance. But taking manual control of sshd_config can be fragile, and can breadk restarts of sshd. I don't recommend it for the faint-hearted and those without test environments with local console access. > So if the above is a requirement for your fictional admin then a tool will > need to be written. > And OpenSSH has already provided the means today by which it can easily > integrate in. Yes, you can hand modify or plug in a wrapper to modify sshd_config and try to keep it consistent with OpenSSH release changes. It's sometimes proven a finicky task. > However, I would hope that it is a well written tool, and it can be shared > with the community > so it doesn't become a one-off burden. Me, too. I haven't noticed any good ones. Even the chef "openssh" cookbook doesn't have good default options for the different OpenSSH variants, and tends to screw up SFTP settings if you use the cookbook. > Anyways, the question still boils down to is Google Authenticator + > Authorized Keys (with or > without password) 2FA. And honestly I'm going to have to state it is 2FA in > both cases. > The argument is simple. If I use a password management tool (that requires > me to unlock > it with a different password) that auto fills in my Blizzard Battle.net > login/password then I use > the Blizzard's authenticator and type in the random code do I have 2FA? I agree with this argument. > Clearly, I've not typed my password. I may NOT EVEN KNOW my password (which > is true > in this case as it is a nasty auto-generated beast =). So it is basically > the same as the > 2048bit RSA authorized key I use in SSH. I use a password to decrypt > access, > but I only really possess both as I don't have them memorized. > To complete the comparison I can write myself a password manager that > doesn't require > me to unlock (e.g. most "remember my password" crap in browsers). So the > fact it is if > my password is protected or not doesn't change my knowledge (or lack of) of > the > password. This is the kind of thing I really, really don't recommend for the faint of heart or the wise of maintenance. This sort of trick quickly leds to the infamous XKCD "automation" chart, shown at https://xkcd.com/1319/ . > The same goes for RSA keys. Someone can steal my password manager, hack it, > and > gain access. Just like they could steal steal my RSA keys off my laptop. > > > Ben People *do* steal private SSH keys and other keys off computers, both laptops and servers, all the time. I've certainly done it as a proof of concept. The last time, it was a "Linux architect" who erected an SSH tunnel between servers at work and his home machine, with unencrypted SSH private keys stored in his home direcotry on ech end, and published on NFS shares. I was pretty shocked, but that kind of thing is not that unusual. Keys get stolen by this kind of silliness *all the time*. From michael at stroeder.com Mon Jul 11 02:05:56 2016 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 10 Jul 2016 18:05:56 +0200 Subject: SSH multi factor authentication In-Reply-To: References: Message-ID: <57827264.2050609@stroeder.com> Bruce F Bading wrote: > There has been some good discussion around our IBM security team as to what > actually constitutes SSH multi factor authentication. In general it's worth to put a lot of thinking in this topic considering how SSH access is used by all your operators. Think of ansible, cluster SSH, fabric and other automation tools for mass administration of many machines via SSH. > There are 2 options > being discussed. > > One, the Google Authenticator (OTP authentication). > Two, Public/Private key authentication (pubkeyauthentication = yes) which > supports pass phrase private key authentication. Security OATH-HOTP or OATH-TOTP relies on keeping a shared secret really secret and securely authenticate it during enrollment process. Personally I don't consider a Smartphone to be a secure secret store. YMMV. > Which of these is considered multi-factor authentication and can you give a > brief response? There are different opinions here and your opinion is > greatly appreciated. Some valuable security aspects were already pointed out by others. Especially you have to restrict the management of SSH authorized keys by some means. Another thing you have to bear in mind is that the usual smart-cards, USB crypto tokens or similar are pretty slow. For one signature operation most devices still need at least ~ one second. That does not sound much but can sum up when accessing managing many machines at once (again: ansible, cluster SSH, fabric). More information upon request since it might be considered off-topic here. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4245 bytes Desc: S/MIME Cryptographic Signature URL: From jjelen at redhat.com Mon Jul 11 18:07:16 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 11 Jul 2016 10:07:16 +0200 Subject: portable sftp oddity: sftp, redirection of stderr and ControPersist In-Reply-To: <577EA897.30701@holland-consulting.net> References: <577EA897.30701@holland-consulting.net> Message-ID: <4bbc0dad-1c42-16aa-827b-19da1be69916@redhat.com> On 07/07/2016 09:07 PM, Nick Holland wrote: > hi, > > Ran into a problem which I thought was an AIXism, but have since found > that it can be reproduced on Linux and MacOS. It can NOT be > reproduced on OpenBSD. > > Reproduced on: > AIXv7.1 OpenSSH v6.0p1 > RedHat 6.8 OpenSSH 5.4p1 > Redhat 7.2 OpenSSH 6.6.1p1 > MacOS 10.11 (sorry, forgot to grab the OpenSSH version) > > Could not reproduce on: > OpenBSD 5.9-current, march snapshot, OpenSSH_7.2 > OpenBSD 5.3-current, April snapshot, OpenSSH_6.2 > > Demonstration: set up an account on a system that can ssh to itself > and authenticate via keys. > > Create and run this script: > ===== > #!/usr/bin/ksh > > mkdir -p ~/dest > > for X in 1 2 3 4 5 6 7 8 9 10; do > echo $X > echo "cd dest > put $0" | sftp -b - localhost 2>&1 | tee -a outfile > done > ===== > > Change first line to whatever shell your system uses (that's AIX's > default), otherwise, should be pretty portable. > > Run it, it should copy itself to a directory in your home directory > ten times, should take just a few seconds. > > > Now, add the following to ~/.ssh/config : > ===== > ControlMaster auto > ControlPath ~/.ssh/control/%h:%r:%p > ControlPersist 10s > ===== > > re-run script. > * What I think should happen is the persistent control channel should > greatly reduce the SSH connection time, so it should run significantly > faster. > > * What DOES happen on platforms with a problem: the "ControlPersist" > value becomes an SSH rate limiter -- instead of holding a connection > OPEN for ten seconds, it PREVENTS another SSH session from starting > for ten seconds! So, instead of taking maybe four seconds before, now > it takes 104 seconds (10 x 10 seconds + ssh connection overhead). > Change the ControlPersist to some other value, the overall speed goes > up or down, but never as fast as without the ControlPersist options in > place. > > > here's where it gets weird. > Remove the "2>&1" from the sftp line, and the problem goes away -- the > script runs much faster with the .ssh/config file than without it. > Unfortunately, I need the stderr output. :-/ > > It appears to be the "2>&1 | {cmd}" structure that is at fault -- > doesn't matter if {cmd} is tee, wc, or a shell function (as it was in > my "real" project). > > I have found that 2>error.file |tee outfile works, and then I can > append the error.file output into the end of the "outfile" and > accomplish my goals, but that's kinda ugly. This looks like related to the bug #1988 [1]. The mux process is holding the stderr. Could you test it with the patch from the referenced bug applied? Also as I see you are using RHEL, you can contact your support to provide a test package (we plan to fix this in RHEL7.3). [1] https://bugzilla.mindrot.org/show_bug.cgi?id=1988 -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From nick at holland-consulting.net Wed Jul 13 22:34:50 2016 From: nick at holland-consulting.net (Nick Holland) Date: Wed, 13 Jul 2016 22:34:50 -0400.4333333333333371 Subject: portable sftp oddity: sftp, redirection of stderr and ControPersist In-Reply-To: <4bbc0dad-1c42-16aa-827b-19da1be69916@redhat.com> References: <577EA897.30701@holland-consulting.net> <4bbc0dad-1c42-16aa-827b-19da1be69916@redhat.com> Message-ID: On 07/11/16 04:06, Jakub Jelen wrote: > On 07/07/2016 09:07 PM, Nick Holland wrote: ... > This looks like related to the bug #1988 [1]. The mux process is holding > the stderr. Could you test it with the patch from the referenced bug > applied? > Also as I see you are using RHEL, you can contact your support to > provide a test package (we plan to fix this in RHEL7.3). > > [1] https://bugzilla.mindrot.org/show_bug.cgi?id=1988 > well, RHEL is what I reproduced the error on, the actual problem cropped up in an AIX project. Just not too easy to test AIX if you don't have power- hungry, outrageously expensive hw on hand. :-/ So. I loaded up a CentOS 7.2 VM, downloaded the most recent OpenSSH-portable tar file (openssh-7.2p2.tar.gz), added zlib-devel and openssl-devel, ./configure, make, make install'd the program. pkill'ed sshd, /usr/local/sbin/sshd to start sshd....and same results. I then applied this patch: diff --git a/log.c b/log.c index a5ba22f..9011f9d 100644 --- a/log.c +++ b/log.c @@ -308,7 +308,7 @@ log_change_level(LogLevel new_log_level) int log_is_on_stderr(void) { - return log_on_stderr; + return log_on_stderr && log_stderr_fd == STDERR_FILENO; } /* redirect what would usually get written to stderr to specified file */ diff --git a/ssh.c b/ssh.c index ec8a515..65e0217 100644 --- a/ssh.c +++ b/ssh.c @@ -1346,7 +1346,7 @@ static void control_persist_detach(void) { pid_t pid; - int devnull; + int devnull, keep_stderr; debug("%s: backgrounding master process", __func__); @@ -1377,8 +1377,10 @@ control_persist_detach(void) error("%s: open(\"/dev/null\"): %s", __func__, strerror(errno)); } else { + keep_stderr = log_is_on_stderr() && debug_flag; if (dup2(devnull, STDIN_FILENO) == -1 || - dup2(devnull, STDOUT_FILENO) == -1) + dup2(devnull, STDOUT_FILENO) == -1 || + (!keep_stderr && dup2(devnull, STDERR_FILENO) == -1)) error("%s: dup2: %s", __func__, strerror(errno)); if (devnull > STDERR_FILENO) close(devnull); and seems to work, at least once I modified my script to use the sftp I had compiled in /usr/local/bin rather than the "factory" /usr/bin (oops). my test script: ==== #!/bin/bash mkdir -p ~/dest for X in 1 2 3 4 5 6 7 8 9 10; do echo $X echo "cd dest put $0" | /usr/local/bin/sftp -b - localhost 2>&1 | tee -a outfile done ==== So yes, looks like there's a fix on the way. Thanks! Nick. From boris at activist.com Thu Jul 14 18:27:42 2016 From: boris at activist.com (Boris A.) Date: Thu, 14 Jul 2016 10:27:42 +0200 Subject: Error when compiling openssh-7.2p2 Message-ID: Hello, friends! I need help. When I compile openssh-7.2p2 I get the error. ./configure .. OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: S/KEY support: no MD5 password support: no libedit support: no Solaris process contract support: no Solaris project support: no Solaris privilege support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Privsep sandbox style: seccomp_filter Host: x86_64-unknown-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all -fPIE Preprocessor flags: Linker flags: -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-all -pie Libraries: -lcrypto -ldl -lutil -lz -lcrypt -lresolv make .. gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all -fPIE -I. -I. -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c ssh_api.c -o ssh_api.o In file included from ssh_api.h:26:0, from ssh_api.c:21: cipher.h:69:17: error: field `evp' has incomplete type EVP_CIPHER_CTX evp; ^ make: *** [ssh_api.o] Error 1 3.19.0-64-generic #72~14.04.1-Ubuntu. Answer in Google I have not found. Thanks for the reply. With best wishes, Boris. From dtucker at zip.com.au Thu Jul 14 19:21:44 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 14 Jul 2016 19:21:44 +1000 Subject: Error when compiling openssh-7.2p2 In-Reply-To: References: Message-ID: On Thu, Jul 14, 2016 at 6:27 PM, Boris A. wrote: [...] > Host: x86_64-unknown-linux-gnu What kind of Linux system is it? In particular, what version of OpenSSL does it have? What options did you give to configure? -- 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 Thu Jul 14 21:12:38 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 14 Jul 2016 21:12:38 +1000 Subject: Error when compiling openssh-7.2p2 In-Reply-To: References: Message-ID: Re-adding the list. On Thu, Jul 14, 2016 at 8:52 PM, Boris A. wrote: > Hi, Darren! > > Linux - 14.04.1-Ubuntu, > OpenSSL 1.1.0-pre5 (beta) 19 Apr 2016, > Only ./configure Because of incompatible changes in it, the OpenSSL 1.1 series it is not currently supported. Use the OpenSSL 1.0.x version that usually ships with Ubuntu instead. http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-February/034834.html -- 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 pmoody at uber.com Tue Jul 19 13:05:12 2016 From: pmoody at uber.com (Peter Moody) Date: Mon, 18 Jul 2016 20:05:12 -0700 Subject: allowing host wildcards in PermitOpen Message-ID: I have a need to be able to permit ssh proxying to any host in prod, but only permit arbitrary ssh port forwards to a very small set of hosts. With the current PermitOpen config syntax, I can only specify a wildcard in the port field, but I would like to be able to add something like the following on my production jumphosts: PermitOpen *:22 special-forwarding-gateway:* the attached patch implements this functionality in the most basic way possible. It's possible people may want fancier filtering (CIDR based, or *.corp.foo.com), I could add that too if you'd prefer. Let me know what sort of CLA you need to have signed. I've gotten the go-ahead from our legal folks to submit this. Cheers, peter From dtucker at zip.com.au Tue Jul 19 16:29:59 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Jul 2016 16:29:59 +1000 Subject: allowing host wildcards in PermitOpen In-Reply-To: References: Message-ID: On Tue, Jul 19, 2016 at 1:05 PM, Peter Moody wrote: > I have a need to be able to permit ssh proxying to any host in prod, > but only permit arbitrary ssh port forwards to a very small set of > hosts. With the current PermitOpen config syntax, I can only specify a > wildcard in the port field, but I would like to be able to add > something like the following on my production jumphosts: > > PermitOpen *:22 special-forwarding-gateway:* > > the attached patch implements this functionality in the most basic way > possible. Your patch got stripped by the list software (it strips any non-text mime types for safety reasons). There's already an open bug for this: https://bugzilla.mindrot.org/show_bug.cgi?id=2582. I'd suggest adding your patch there (and maybe comparing it to the other implementation). > It's possible people may want fancier filtering (CIDR based, > or *.corp.foo.com), I could add that too if you'd prefer. > > Let me know what sort of CLA you need to have signed. I've gotten the > go-ahead from our legal folks to submit this. As long as any new code is licensed under BSD-compatible terms[1] it should be fine. For new code we prefer ISC[2] style but from your description is sounds like there may not be a significant piece of new work. [1] http://www.openbsd.org/policy.html [1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/misc/license.template?rev=HEAD -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From coredump at autistici.org Tue Jul 19 23:10:48 2016 From: coredump at autistici.org (C0r3dump3d) Date: Tue, 19 Jul 2016 15:10:48 +0200 Subject: Openssh use enumeration Message-ID: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Hi, sorry I don't know if I send this to the correct channel. I have notice that OpenSSH has recognized the presence of the user enumeration as a vulnerability, http://seclists.org/fulldisclosure/2016/Jul/51 (CVE-2016-6210). I want to make an appreciation, this is a old vulnerability already announced three years ago. https://blog.curesec.com/article/blog/OpenSSH-User-Enumeration-Time-Based-Attack-20.html http://seclists.org/fulldisclosure/2013/Jul/88 http://www.behindthefirewalls.com/2014/07/openssh-user-enumeration-time-based.html I would like to point out that there is another vulnerability present in the bug, it's possible in certain circumstances to provoke a DOS condition in the access to the ssh server, I made a brief study of this possibility here: https://www.devconsole.info/?p=382 and included this attack in my tool that exploit this vulnerability: https://github.com/c0r3dump3d/osueta It's necessary to request another CVE-ID for the DOS attack? At least, I think it should be clarified in the announce of the vulnerability. Regards. From thomas at glanzmann.de Wed Jul 20 19:06:44 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 20 Jul 2016 11:06:44 +0200 Subject: OpenSSH_6.7p1 Debian-5+deb8u2 unix socket forwarding: Warning: remote port forwarding failed for listen path /home/sithglan/.gnupg/S.gpg-agent Message-ID: <20160720090644.GA24242@glanzmann.de> Hello, I would like to forward my gpg-agent from a local workstation using a remote machine: (x1) [~] ssh -o "StreamLocalBindUnlink=yes" -R /home/sithglan/.gnupg/S.gpg-agent:/home/sithglan/.gnupg/S.gpg-agent remote.machine.de when I do the same, I get the following error message: Warning: remote port forwarding failed for listen path /home/sithglan/.gnupg/S.gpg-agent >From my understanding StreamLocalBindUnlink=yes should delete the remote listining socket before forwarding it. On the web other user report that it is broken and someone should use a ~/.ssh/rc file to fight the symptoms. My question is: Should it work like the above? Am I doing something wrong? Is it fixed in a newer version and should I upgrade? I'm using Debian Jessie 64 Bit, but fine with updating or patching sshd to enable above usecase. Otherwise I'll go with the ~/.ssh/rc file. Cheers, Thomas From thomas at glanzmann.de Wed Jul 20 21:30:23 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 20 Jul 2016 13:30:23 +0200 Subject: OpenSSH_6.7p1 Debian-5+deb8u2 unix socket forwarding: Warning: remote port forwarding failed for listen path /home/sithglan/.gnupg/S.gpg-agent In-Reply-To: <20160720090644.GA24242@glanzmann.de> References: <20160720090644.GA24242@glanzmann.de> Message-ID: <20160720113023.GA28540@glanzmann.de> Hello everyone, > (x1) [~] ssh -o "StreamLocalBindUnlink=yes" -R /home/sithglan/.gnupg/S.gpg-agent:/home/sithglan/.gnupg/S.gpg-agent remote.machine.de > Warning: remote port forwarding failed for listen path /home/sithglan/.gnupg/S.gpg-agent to answer my own question. StreamLocalBindUnlink exists for client and for server. In order to make a remote port forwarding work with an existing socket, it needs to be enabled in the server, not in the client. So the following works: (infra) [~] grep StreamLocalBindUnlink /etc/ssh/sshd_config StreamLocalBindUnlink yes (infra) [~] /etc/init.d/ssh restart Restarting OpenBSD Secure Shell server: sshd. Afterwards it works like a charm. Cheers, Thomas From dtucker at zip.com.au Thu Jul 21 11:45:38 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 11:45:38 +1000 Subject: Openssh use enumeration In-Reply-To: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: On Tue, Jul 19, 2016 at 11:10 PM, C0r3dump3d wrote: > Hi, sorry I don't know if I send this to the correct channel. It is. [..] > it's possible in certain circumstances to provoke a DOS > condition in the access to the ssh server. We have been discussing this a bit, and what we have just added is a simple hard limit on the allowed size of a password string at 1k, above which the password is immediately refused. There's other possible embellishments (eg, add a possibly variable delay) but we haven't decided on any yet. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From selphie.keller at gmail.com Thu Jul 21 12:18:57 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Wed, 20 Jul 2016 20:18:57 -0600 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: I thought this was already addressed with the internal blowfish hash of "$2a$06$r3.juUaHZDlIbQaO2dS9FuYxL1W9M81R1Tc92PoSNmzvpEqLkLGrK" to where all passwords were checked against this to prevent timing analysis for user enumeration. On 20 July 2016 at 19:45, Darren Tucker wrote: > On Tue, Jul 19, 2016 at 11:10 PM, C0r3dump3d > wrote: > > Hi, sorry I don't know if I send this to the correct channel. > > It is. > > [..] > > it's possible in certain circumstances to provoke a DOS > > condition in the access to the ssh server. > > We have been discussing this a bit, and what we have just added is a > simple hard limit on the allowed size of a password string at 1k, > above which the password is immediately refused. There's other > possible embellishments (eg, add a possibly variable delay) but we > haven't decided on any yet. > > Thanks. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > 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 selphie.keller at gmail.com Thu Jul 21 12:31:34 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Wed, 20 Jul 2016 20:31:34 -0600 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: Ahh i see, just got up to speed on the issue, so seems like the issue is related to blowfish being faster then sha family hashing for longer length passwords, so there is a time lag difference between the blowfish internal hash and the sha family hash, though this could be tricky to fix since some systems may still use blowfish based hashing and changing the internal hash from blowfish to sha to fix this for modern systems may invalidate it inversely on older systems, where this attack can be done to find the difference in the other direction of taking to long. Some sorta of hybrid solution of computing hashes based on what the system is actively using should resolve the timing issue. So if this is on a newer system using sha family for hashing it would use a sha family hash to be the fall back for accounts and blowfish if it's on a system using blowfish. On 20 July 2016 at 20:18, Selphie Keller wrote: > I thought this was already addressed with the internal blowfish hash of > "$2a$06$r3.juUaHZDlIbQaO2dS9FuYxL1W9M81R1Tc92PoSNmzvpEqLkLGrK" to where all > passwords were checked against this to prevent timing analysis for user > enumeration. > > On 20 July 2016 at 19:45, Darren Tucker wrote: > >> On Tue, Jul 19, 2016 at 11:10 PM, C0r3dump3d >> wrote: >> > Hi, sorry I don't know if I send this to the correct channel. >> >> It is. >> >> [..] >> > it's possible in certain circumstances to provoke a DOS >> > condition in the access to the ssh server. >> >> We have been discussing this a bit, and what we have just added is a >> simple hard limit on the allowed size of a password string at 1k, >> above which the password is immediately refused. There's other >> possible embellishments (eg, add a possibly variable delay) but we >> haven't decided on any yet. >> >> Thanks. >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA >> (new) >> 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 dtucker at zip.com.au Thu Jul 21 12:48:46 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 12:48:46 +1000 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller wrote: > Ahh i see, just got up to speed on the issue, so seems like the issue is > related to blowfish being faster then sha family hashing for longer length > passwords, or the system's crypt() not understanding $2a$ -style salts, which most glibcs don't. On those, crypt fails immediately due to invalid salt. > so there is a time lag difference between the blowfish internal > hash and the sha family hash, though this could be tricky to fix since some > systems may still use blowfish based hashing and changing the internal hash The best I could come up with (which is what I implemented[1]) was to look the crypt method used for root's password and use that, falling back to DES if that fails. That scheme won't help if you don't set a root password (or set it to *LK* or similar), but short of surveying all accounts on the system I'm not sure how to do much better. [1] https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b5e50692739d314cd8d9dc -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From selphie.keller at gmail.com Thu Jul 21 13:02:57 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Wed, 20 Jul 2016 21:02:57 -0600 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: I wonder if could be useful to set the fall back account to something user defined to avoid suggesting people add passwords to root, though I do like root since the account is always there, but I myself would do that invalid pass before actually adding a real pass to root, however I think it would be nice if there was a sshd_config option for fallback_timing_account to let the user specify something other then root like some generic user they already have that doesn't involve root. Or have ssh create an dummy account on the system that has only a invalid password. The fall back to DES seems ok, but not sure it would fully resolve the issue, since timing for DES and sha family would be different, but does fix the instant fail for crypt not understanding blowfish. The random delay idea is pretty good it would make timing analysis difficult. I wonder if DES + random delay in event root has no password could be an option. On 20 July 2016 at 20:48, Darren Tucker wrote: > On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller > wrote: > > Ahh i see, just got up to speed on the issue, so seems like the issue is > > related to blowfish being faster then sha family hashing for longer > length > > passwords, > > or the system's crypt() not understanding $2a$ -style salts, which > most glibcs don't. On those, crypt fails immediately due to invalid > salt. > > > so there is a time lag difference between the blowfish internal > > hash and the sha family hash, though this could be tricky to fix since > some > > systems may still use blowfish based hashing and changing the internal > hash > > The best I could come up with (which is what I implemented[1]) was to > look the crypt method used for root's password and use that, falling > back to DES if that fails. That scheme won't help if you don't set a > root password (or set it to *LK* or similar), but short of surveying > all accounts on the system I'm not sure how to do much better. > > [1] > https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b5e50692739d314cd8d9dc > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Thu Jul 21 13:18:00 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 13:18:00 +1000 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: <20160721031800.GA17245@gate.dtucker.net> On Wed, Jul 20, 2016 at 09:02:57PM -0600, Selphie Keller wrote: > I wonder if could be useful to set the fall back account to something user > defined to avoid suggesting people add passwords to root, though I do like > root since the account is always there, Since committing that diff I've heard of people running in production with no root password (ie *LK*, !! or similar). It's about the same amount of code to search for the first account with a valid salt, which would avoid this problem in the case where the root account doesn't have a real password. djm: what do you think? diff --git a/openbsd-compat/xcrypt.c b/openbsd-compat/xcrypt.c index 8913bb8..5385243 100644 --- a/openbsd-compat/xcrypt.c +++ b/openbsd-compat/xcrypt.c @@ -78,14 +78,18 @@ pick_salt(void) if (salt[0] != '\0') return salt; strlcpy(salt, "xx", sizeof(salt)); - if ((pw = getpwuid(0)) == NULL) - return salt; - passwd = shadow_pw(pw); - if (passwd[0] != '$' || (p = strrchr(passwd + 1, '$')) == NULL) - return salt; /* no $, DES */ - typelen = p - passwd + 1; - strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); - explicit_bzero(passwd, strlen(passwd)); + setpwent(); + while ((pw = getpwent()) != NULL) { + passwd = shadow_pw(pw); + if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) != NULL) { + typelen = p - passwd + 1; + strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); + explicit_bzero(passwd, strlen(passwd)); + goto out; + } + } + out: + endpwent(); return salt; } -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From selphie.keller at gmail.com Thu Jul 21 13:34:07 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Wed, 20 Jul 2016 21:34:07 -0600 Subject: Openssh use enumeration In-Reply-To: <20160721031800.GA17245@gate.dtucker.net> References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <20160721031800.GA17245@gate.dtucker.net> Message-ID: yeah I like this idea, fixes the issue with blowfish hashes and non root passwords, maybe random delay as the final fall back if no salts/passwords are found. Seems rare, but I do have one box that I use ssh keys on and none of the accounts have a hash set, but I also don't have password auth enabled. On 20 July 2016 at 21:18, Darren Tucker wrote: > On Wed, Jul 20, 2016 at 09:02:57PM -0600, Selphie Keller wrote: > > I wonder if could be useful to set the fall back account to something > user > > defined to avoid suggesting people add passwords to root, though I do > like > > root since the account is always there, > > Since committing that diff I've heard of people running in production > with no root password (ie *LK*, !! or similar). > > It's about the same amount of code to search for the first account with > a valid salt, which would avoid this problem in the case where the root > account doesn't have a real password. > > djm: what do you think? > > diff --git a/openbsd-compat/xcrypt.c b/openbsd-compat/xcrypt.c > index 8913bb8..5385243 100644 > --- a/openbsd-compat/xcrypt.c > +++ b/openbsd-compat/xcrypt.c > @@ -78,14 +78,18 @@ pick_salt(void) > if (salt[0] != '\0') > return salt; > strlcpy(salt, "xx", sizeof(salt)); > - if ((pw = getpwuid(0)) == NULL) > - return salt; > - passwd = shadow_pw(pw); > - if (passwd[0] != '$' || (p = strrchr(passwd + 1, '$')) == NULL) > - return salt; /* no $, DES */ > - typelen = p - passwd + 1; > - strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); > - explicit_bzero(passwd, strlen(passwd)); > + setpwent(); > + while ((pw = getpwent()) != NULL) { > + passwd = shadow_pw(pw); > + if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) != > NULL) { > + typelen = p - passwd + 1; > + strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); > + explicit_bzero(passwd, strlen(passwd)); > + goto out; > + } > + } > + out: > + endpwent(); > return salt; > } > > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Thu Jul 21 13:48:03 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 13:48:03 +1000 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <20160721031800.GA17245@gate.dtucker.net> Message-ID: On Thu, Jul 21, 2016 at 1:34 PM, Selphie Keller wrote: > yeah I like this idea, fixes the issue with blowfish hashes and non root > passwords, maybe random delay as the final fall back if no salts/passwords > are found. Well if there are no accounts with a valid salt then there's also no valid account to compare the timing of invalid accounts against. Worst case that'd be DES crypt vs empty password and I'm not sure if you'd be able to pick that out of the background crypto. > Seems rare, but I do have one box that I use ssh keys on and none > of the accounts have a hash set, but I also don't have password auth > enabled. IMO random delays are overrated for mitigating timing attacks; you can look for inconsistent behaviour as the indicator of whatever you're looking for. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From opensshdev at r.paypc.com Thu Jul 21 14:00:51 2016 From: opensshdev at r.paypc.com (Morham Anthelleron) Date: Wed, 20 Jul 2016 21:00:51 -0700 Subject: Openssh use enumeration In-Reply-To: <20160721031800.GA17245@gate.dtucker.net> References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <20160721031800.GA17245@gate.dtucker.net> Message-ID: <1469073651.579048f3d209d5.32863245@www.paypc.com> Quoting Darren Tucker : > Since committing that diff I've heard of people running in production > with no root password (ie *LK*, !! or similar). > > It's about the same amount of code to search for the first account with > a valid salt, which would avoid this problem in the case where the root > account doesn't have a real password. > > djm: what do you think? Since OpenSSH already makes use of an unprivileged user for privsep, why not take the next step of setting a (long) random password for it using the system's normal shadow password routines? If one is concerned about an accidentally "successful" login, you could perturb the supplied passphrase prior to passing it down to the authentication library to ensure a successful entry is impossible. Alternately, a second "dummy" account that's not used at all by the system which is a chroot jail with nothing in it with a random password? This way no bizarre system assumptions need be made, and it accommodates the wide range of "policy" preferences for the bulk of the userbase. =M= From dtucker at zip.com.au Thu Jul 21 14:16:14 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 14:16:14 +1000 Subject: Openssh use enumeration In-Reply-To: <1469073651.579048f3d209d5.32863245@www.paypc.com> References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <20160721031800.GA17245@gate.dtucker.net> <1469073651.579048f3d209d5.32863245@www.paypc.com> Message-ID: On Thu, Jul 21, 2016 at 2:00 PM, Morham Anthelleron wrote: [...] > Since OpenSSH already makes use of an unprivileged user for privsep, why not > take the next step of setting a (long) random password for it using the > system's normal shadow password routines? Assuming you mean putpwent(): that requires an encrypted string to put in pw_passwd putting us right back where we started. > If one is concerned about an accidentally "successful" login, you could > perturb the supplied passphrase prior to passing it down to the authentication > library to ensure a successful entry is impossible. > > Alternately, a second "dummy" account that's not used at all by the system > which is a chroot jail with nothing in it with a random password? If we could reliably come up with the encrypted string to put in that dummy account we wouldn't need the dummy account. Actually setting a password is quite system dependent. exec'ing /bin/passwd in most cases needs a controlling terminal although some have flags for reading form stdin. Using pam_chauthtok() would require making assumptions about what the prompts were. Some systems enforce complexity (as opposed to entropy) requirements. And then you'd have an account with a password that you're not quite sure where it came from. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Jul 21 14:27:04 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 14:27:04 +1000 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <20160721031800.GA17245@gate.dtucker.net> Message-ID: On Thu, Jul 21, 2016 at 1:48 PM, Darren Tucker wrote: [...] > Well if there are no accounts with a valid salt then there's also no > valid account to compare the timing of invalid accounts against. > Worst case that'd be DES crypt vs empty password and I'm not sure if > you'd be able to pick that out of the background crypto. I just measured the speed of DES crypt on a somewhat elderly 2.1GHz Xeon X3210 at about 7 microseconds. Good luck picking that out of Diffie-Hellman exchange over a network. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From selphie.keller at gmail.com Thu Jul 21 14:36:58 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Wed, 20 Jul 2016 22:36:58 -0600 Subject: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <20160721031800.GA17245@gate.dtucker.net> Message-ID: Darren, If you have time could you try the actual tool against the new patch curious to see how it stands up https://github.com/c0r3dump3d/osueta On 20 July 2016 at 22:27, Darren Tucker wrote: > On Thu, Jul 21, 2016 at 1:48 PM, Darren Tucker wrote: > [...] > > Well if there are no accounts with a valid salt then there's also no > > valid account to compare the timing of invalid accounts against. > > Worst case that'd be DES crypt vs empty password and I'm not sure if > > you'd be able to pick that out of the background crypto. > > I just measured the speed of DES crypt on a somewhat elderly 2.1GHz > Xeon X3210 at about 7 microseconds. Good luck picking that out of > Diffie-Hellman exchange over a network. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From Roman.Fiedler at ait.ac.at Thu Jul 21 17:59:53 2016 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 21 Jul 2016 07:59:53 +0000 Subject: AW: Openssh use enumeration In-Reply-To: References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> Message-ID: <2ECE9D9EEF1F524185270138AE23265954FB7980@S0MSMAIL112.arc.local> > From: openssh-unix-dev > > I wonder if could be useful to set the fall back account to something user > defined to avoid suggesting people add passwords to root, though I do like > root since the account is always there, but I myself would do that invalid > pass before actually adding a real pass to root, however I think it would > be nice if there was a sshd_config option for fallback_timing_account to > let the user specify something other then root like some generic user they > already have that doesn't involve root. Or have ssh create an dummy account > on the system that has only a invalid password. The fall back to DES seems > ok, but not sure it would fully resolve the issue, since timing for DES and > sha family would be different, but does fix the instant fail for crypt not > understanding blowfish. The random delay idea is pretty good it would make > timing analysis difficult. I wonder if DES + random delay in event root has > no password could be an option. Why not use the settings from /etc/login.defs? # If set to MD5 , MD5-based algorithm will be used for encrypting password # If set to SHA256, SHA256-based algorithm will be used for encrypting password # If set to SHA512, SHA512-based algorithm will be used for encrypting password # If set to DES, DES-based algorithm will be used for encrypting password (default) # Overrides the MD5_CRYPT_ENAB option # # Note: It is recommended to use a value consistent with # the PAM modules configuration. # ENCRYPT_METHOD SHA512 /usr/bin/passwd from "shadow" package goes down the same way when setting passwords. So perhaps following code would be hard to do timing analysis for: * Get default hash method from login.def * Get/create a fake crypted passwd for the method/salt being default. * Get the pwent for the user name requested * When user not found: get the entry for root and discard the result * When user check succeeded: get the entry for the user "nonexisting:xxxx" - I think ':' is forbidden, so name should never exist (TODO: check side effects) * Compare the supplied passwd with the fake or real hash * Do what has to be done. What do you think? Only easy timing attacks should be on systems where DefaultMethod!=all password methods, which could be deemed a configuration error. Roman > On 20 July 2016 at 20:48, Darren Tucker wrote: > > > On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller > > wrote: > > > Ahh i see, just got up to speed on the issue, so seems like the issue is > > > related to blowfish being faster then sha family hashing for longer > > length > > > passwords, > > > > or the system's crypt() not understanding $2a$ -style salts, which > > most glibcs don't. On those, crypt fails immediately due to invalid > > salt. > > > > > so there is a time lag difference between the blowfish internal > > > hash and the sha family hash, though this could be tricky to fix since > > some > > > systems may still use blowfish based hashing and changing the internal > > hash > > > > The best I could come up with (which is what I implemented[1]) was to > > look the crypt method used for root's password and use that, falling > > back to DES if that fails. That scheme won't help if you don't set a > > root password (or set it to *LK* or similar), but short of surveying > > all accounts on the system I'm not sure how to do much better. > > > > [1] > > > https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b > 5e50692739d314cd8d9dc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6344 bytes Desc: not available URL: From dtucker at zip.com.au Thu Jul 21 18:36:23 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Jul 2016 18:36:23 +1000 Subject: Openssh use enumeration In-Reply-To: <2ECE9D9EEF1F524185270138AE23265954FB7980@S0MSMAIL112.arc.local> References: <1743a388-4e01-dbd1-2408-33f821384d9f@autistici.org> <2ECE9D9EEF1F524185270138AE23265954FB7980@S0MSMAIL112.arc.local> Message-ID: On Thu, Jul 21, 2016 at 5:59 PM, Fiedler Roman wrote: > Why not use the settings from /etc/login.defs? That's (I think) Linux only. FreeBSD has /etc/login.conf which is a different format. No idea what Solaris has but it doesn't seem to be either of those. No idea about the other dozen or more platforms we run on. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jweisblat at yahoo-inc.com Fri Jul 22 10:48:18 2016 From: jweisblat at yahoo-inc.com (jweisblat at yahoo-inc.com) Date: Fri, 22 Jul 2016 00:48:18 +0000 (UTC) Subject: ssh-agent: loading a PKCS#11 library without a private key on disk References: <983901469.2934823.1469148498769.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <983901469.2934823.1469148498769.JavaMail.yahoo@mail.yahoo.com> Hello, As far as I can tell, the following is a reasonable and useful authentication mechanism but not curently implemented in OpenSSH's agent, but possible with the most recent client version. I'd like to propose an addition to the agent protocol to allow this authentication mechanism. The authentication mechanism: certificate-based authentication combined with a PIV smartcard for the key. That is, store the private key in PIV hardware, which is currently supported in the agent for use with traditional public-key authentication (publickey is on server, private key is in hardware, accessed through PKCS#11 library) with SSH_AGENTC_ADD_SMARTCARD_KEY and SSH_AGENTC_REMOVE_SMARTCARD_KEY, but provide a certificate from a certificate authority allowing login with a given publickey for a certain amount of time with certain usernames, etc. This is currently allowed by having a certificate on the filesystem and referencing it with an IdentityFile directive in .ssh/config, but it breaks with agent forwarding. It's impossible with the status quo to add a certificate to the agent without the private key - the protocol doesn't allow it: RSA certificates may be added with this request: byte SSH2_AGENTC_ADD_IDENTITY or SSH2_AGENTC_ADD_ID_CONSTRAINED string "ssh-rsa-cert-v00 at openssh.com" string certificate mpint rsa_d mpint rsa_iqmp mpint rsa_p mpint rsa_q string key_comment constraint[] key_constraints Adding a certificate to the agent requires adding privatekey material as well. I'd be willing to implement a new method for adding a smartcard with associated certificate, or I'd be willing to implement a mechanism for adding RSA certificates without a corresponding privatekey, or am alternate to other proposed solutions, depending on what feedback I get on this. Thanks, Jakob WeisblatParanoid LabsYahoo! Inc I've included a plaintext copy of my previous email, which was garbled by my mailserver upon conversion to plaintext, below. --------------------------------------------------------------------------------------------------- Hello, Several of my coworkers and I, as well as others, have been confused by the behavior of `ssh-add -D`. From the man page: ? ? ?-D ? ? ?Deletes all identities from the agent. The current behavior of `ssh-add -D` is to send SSH2_AGENTC_REMOVE_ALL_IDENTITIES and SSH_AGENTC_REMOVE_ALL_RSA_IDENTITIES to the agent, removing all the keys from the agent, including any keys added via PKCS#11 libraries. However, the PKCS#11 library is still loaded in the agent, and it won't be unloaded (and thus fails to be reloaded, with an unhelpful error) unless SSH_AGENTC_REMOVE_SMARTCARD_KEY is sent, and that takes a parameter of the specific PKCS#11 library involved. Is this behavior the intended behavior of `ssh-add -D`? If it is, we'd be happy to introduce a patch to improve the error message to suggest trying to remove it first. If not, I can imagine several solutions, which we'd be happy to implement, depending on which the community thinks is best: ?- change the behavior of the agent to remove the smartcard in addition to the corresponding identity when SSH2_AGENTC_REMOVE_ALL_IDENTITIES is run. This is somewhat inideal in the case of that identity being used with protocol version 1.?- add a new agent command SSH_AGENTC_REMOVE_ALL_SMARTCARD_KEYS in addition to SSH_AGENTC_REMOVE_SMARTCARD_KEY that removes all smartcard keys, modify the agent to accept it and modify ssh-add to send it in addition to the other 2 commands on `ssh -D`. Here is a demonstration of current behavior: [~]$ ssh-add -l? The agent has no identities.[~]$ ssh-add -s /usr/local/lib/libykcs11.dylib? Enter passphrase for PKCS#11:? Card added: /usr/local/lib/libykcs11.dylib[~]$ ssh-add -l? 2048 SHA256:cJUGM7tTnFD9a0BpI936ERA3Ay+/MFu3huzB+APPoZs /usr/local/lib/libykcs11.dylib (RSA)[~]$ ssh-add -D? All identities removed.[~]$ ssh-add -l? The agent has no identities.[~]$ ssh-add -s /usr/local/lib/libykcs11.dylib # Add the card back into the agent, it wasn't unloaded by?? Enter passphrase for PKCS#11:? Could not add card "/usr/local/lib/libykcs11.dylib": agent refused operation[~]$ ssh-add -l? The agent has no identities.[~]$ ssh-add -e /usr/local/lib/libykcs11.dylib? Card removed: /usr/local/lib/libykcs11.dylib[~]$ ssh-add -l? The agent has no identities.[~]$ ssh-add -s /usr/local/lib/libykcs11.dylib? Enter passphrase for PKCS#11:? Card added: /usr/local/lib/libykcs11.dylib[~]$ ssh-add -l? 2048 SHA256:cJUGM7tTnFD9a0BpI936ERA3Ay+/MFu3huzB+APPoZs /usr/local/lib/libykcs11.dylib (RSA)[~]$ From djm at mindrot.org Fri Jul 22 14:40:04 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Jul 2016 14:40:04 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 Message-ID: Hi, OpenSSH 5.3 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs or via Git at https://anongit.mindrot.org/openssh.git/ Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Changes since OpenSSH 7.2 ========================= This is primarily a bugfix release. Security -------- * sshd(8): Mitigate a potential denial-of-service attack against the system's crypt(3) function via sshd(8). An attacker could send very long passwords that would cause excessive CPU use in crypt(3). sshd(8) now refuses to accept password authentication requests of length greater than 1024 characters. Independently reported by Tomas Kuthan (Oracle) and curesec via coredump at autistici.org. * sshd(8): Mitigate timing differences in password authentication that could be used to discern valid from invalid account names when long passwords were sent and particular password hashing algorithms are in use on the server. CVE-2016-6210, reported by EddieEzra.Harari at verint.com * ssh(1), sshd(8): Fix observable timing weakness in the CBC padding oracle countermeasures. Reported by Jean Paul Degabriele, Kenny Paterson, Torben Hansen and Martin Albrecht. Note that CBC ciphers are disabled by default and only included for legacy compatibility. * ssh(1), sshd(8): Improve ordering ordering of MAC verification for Encrypt-then-MAC (EtM) mode transport MAC algorithms to verify the MAC before decrypting any ciphertext. This removes the possibility of timing differences leaking facts about the plaintext, though no such leakage has been observed. Reported by Jean Paul Degabriele, Kenny Paterson, Torben Hansen and Martin Albrecht. * sshd(8): (portable only) Ignore PAM environment vars when UseLogin=yes. If PAM is configured to read user-specified environment variables and UseLogin=yes in sshd_config, then a hostile local user may attack /bin/login via LD_PRELOAD or similar environment variables set via PAM. CVE-2015-8325, found by Shayan Sadigh. New Features ------------ * ssh(1): Add a ProxyJump option and corresponding -J command-line flag to allow simplified indirection through a one or more SSH bastions or "jump hosts". * ssh(1): Add an IdentityAgent option to allow specifying specific agent sockets instead of accepting one from the environment. * ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be optionally overridden when using ssh -W. bz#2577 * ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per draft-sgtatham-secsh-iutf8-00. * ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. * ssh-keygen(1), ssh(1), sshd(8): support SHA256 and SHA512 RSA signatures in certificates; * ssh(1): Add an Include directive for ssh_config(5) files. * ssh(1): Permit UTF-8 characters in pre-authentication banners sent from the server. bz#2058 Bugfixes -------- * ssh(1), sshd(8): Reduce the syslog level of some relatively common protocol events from LOG_CRIT. bz#2585 * sshd(8): Refuse AuthenticationMethods="" in configurations and accept AuthenticationMethods=any for the default behaviour of not requiring multiple authentication. bz#2398 * sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN ATTEMPT!" message when forward and reverse DNS don't match. bz#2585 * ssh(1): Close ControlPersist background process stderr except in debug mode or when logging to syslog. bz#1988 * misc: Make PROTOCOL description for direct-streamlocal at openssh.com channel open messages match deployed code. bz#2529 * ssh(1): Deduplicate LocalForward and RemoteForward entries to fix failures when both ExitOnForwardFailure and hostname canonicalisation are enabled. bz#2562 * sshd(8): Remove fallback from moduli to obsolete "primes" file that was deprecated in 2001. bz#2559. * sshd_config(5): Correct description of UseDNS: it affects ssh hostname processing for authorized_keys, not known_hosts; bz#2554 * ssh(1): Fix authentication using lone certificate keys in an agent without corresponding private keys on the filesystem. bz#2550 * sshd(8): Send ClientAliveInterval pings when a time-based RekeyLimit is set; previously keepalive packets were not being sent. bz#2252 Portability ----------- * ssh(1), sshd(8): Fix compilation by automatically disabling ciphers not supported by OpenSSL. bz#2466 * misc: Fix compilation failures on some versions of AIX's compiler related to the definition of the VA_COPY macro. bz#2589 * sshd(8): Whitelist more architectures to enable the seccomp-bpf sandbox. bz#2590 * ssh-agent(1), sftp-server(8): Disable process tracing on Solaris using setpflags(__PROC_PROTECT, ...). bz#2584 * sshd(8): On Solaris, don't call Solaris setproject() with UsePAM=yes it's PAM's responsibility. bz#2425 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 djm at mindrot.org Fri Jul 22 14:55:56 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Jul 2016 14:55:56 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Fri, 22 Jul 2016, Damien Miller wrote: > Hi, > > OpenSSH 5.3 is almost ready for release, so we would appreciate testing s/5.3/7.3/ and I'd better get myself another cup of tea From doctor at doctor.nl2k.ab.ca Fri Jul 22 14:51:17 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 21 Jul 2016 22:51:17 -0600 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: <20160722045117.GA36651@doctor.nl2k.ab.ca> On Fri, Jul 22, 2016 at 02:40:04PM +1000, Damien Miller wrote: > Hi, > > OpenSSH 5.3 is almost ready for release, so we would appreciate testing ^ Huh? > on as many platforms and systems as possible. This release contains some > substantial new features and a number of bugfixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Git at https://anongit.mindrot.org/openssh.git/ > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the ChangeLog > in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > Changes since OpenSSH 7.2 > ========================= > > This is primarily a bugfix release. > > Security > -------- > > * sshd(8): Mitigate a potential denial-of-service attack against > the system's crypt(3) function via sshd(8). An attacker could > send very long passwords that would cause excessive CPU use in > crypt(3). sshd(8) now refuses to accept password authentication > requests of length greater than 1024 characters. Independently > reported by Tomas Kuthan (Oracle) and curesec via coredump at > autistici.org. > > * sshd(8): Mitigate timing differences in password authentication > that could be used to discern valid from invalid account names > when long passwords were sent and particular password hashing > algorithms are in use on the server. CVE-2016-6210, reported by > EddieEzra.Harari at verint.com > > * ssh(1), sshd(8): Fix observable timing weakness in the CBC padding > oracle countermeasures. Reported by Jean Paul Degabriele, Kenny > Paterson, Torben Hansen and Martin Albrecht. Note that CBC ciphers > are disabled by default and only included for legacy compatibility. > > * ssh(1), sshd(8): Improve ordering ordering of MAC verification for > Encrypt-then-MAC (EtM) mode transport MAC algorithms to verify the > MAC before decrypting any ciphertext. This removes the possibility > of timing differences leaking facts about the plaintext, though no > such leakage has been observed. Reported by Jean Paul Degabriele, > Kenny Paterson, Torben Hansen and Martin Albrecht. > > * sshd(8): (portable only) Ignore PAM environment vars when > UseLogin=yes. If PAM is configured to read user-specified > environment variables and UseLogin=yes in sshd_config, then a > hostile local user may attack /bin/login via LD_PRELOAD or > similar environment variables set via PAM. CVE-2015-8325, > found by Shayan Sadigh. > > New Features > ------------ > > * ssh(1): Add a ProxyJump option and corresponding -J command-line > flag to allow simplified indirection through a one or more SSH > bastions or "jump hosts". > > * ssh(1): Add an IdentityAgent option to allow specifying specific > agent sockets instead of accepting one from the environment. > > * ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be > optionally overridden when using ssh -W. bz#2577 > > * ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as > per draft-sgtatham-secsh-iutf8-00. > > * ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman > 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. > > * ssh-keygen(1), ssh(1), sshd(8): support SHA256 and SHA512 RSA > signatures in certificates; > > * ssh(1): Add an Include directive for ssh_config(5) files. > > * ssh(1): Permit UTF-8 characters in pre-authentication banners sent > from the server. bz#2058 > > Bugfixes > -------- > > * ssh(1), sshd(8): Reduce the syslog level of some relatively common > protocol events from LOG_CRIT. bz#2585 > > * sshd(8): Refuse AuthenticationMethods="" in configurations and > accept AuthenticationMethods=any for the default behaviour of not > requiring multiple authentication. bz#2398 > > * sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN > ATTEMPT!" message when forward and reverse DNS don't match. bz#2585 > > * ssh(1): Close ControlPersist background process stderr except > in debug mode or when logging to syslog. bz#1988 > > * misc: Make PROTOCOL description for direct-streamlocal at openssh.com > channel open messages match deployed code. bz#2529 > > * ssh(1): Deduplicate LocalForward and RemoteForward entries to fix > failures when both ExitOnForwardFailure and hostname > canonicalisation are enabled. bz#2562 > > * sshd(8): Remove fallback from moduli to obsolete "primes" file > that was deprecated in 2001. bz#2559. > > * sshd_config(5): Correct description of UseDNS: it affects ssh > hostname processing for authorized_keys, not known_hosts; bz#2554 > > * ssh(1): Fix authentication using lone certificate keys in an agent > without corresponding private keys on the filesystem. bz#2550 > > * sshd(8): Send ClientAliveInterval pings when a time-based > RekeyLimit is set; previously keepalive packets were not being > sent. bz#2252 > > Portability > ----------- > > * ssh(1), sshd(8): Fix compilation by automatically disabling ciphers > not supported by OpenSSL. bz#2466 > > * misc: Fix compilation failures on some versions of AIX's compiler > related to the definition of the VA_COPY macro. bz#2589 > > * sshd(8): Whitelist more architectures to enable the seccomp-bpf > sandbox. bz#2590 > > * ssh-agent(1), sftp-server(8): Disable process tracing on Solaris > using setpflags(__PROC_PROTECT, ...). bz#2584 > > * sshd(8): On Solaris, don't call Solaris setproject() with > UsePAM=yes it's PAM's responsibility. bz#2425 > > 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. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Language is the source of misunderstandings. -Antoine de Saint-Exupery From dtucker at zip.com.au Fri Jul 22 15:54:21 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Jul 2016 15:54:21 +1000 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722045117.GA36651@doctor.nl2k.ab.ca> References: <20160722045117.GA36651@doctor.nl2k.ab.ca> Message-ID: On Fri, Jul 22, 2016 at 2:51 PM, The Doctor wrote: > On Fri, Jul 22, 2016 at 02:40:04PM +1000, Damien Miller wrote: [...] >> OpenSSH 5.3 is almost ready for release, so we would appreciate testing > ^ > Huh? Either a clone of Damien has been frozen Austin Powers style since 2009 and has only just been thawed out or maybe it was a typo. Tough to tell. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Jul 22 16:53:46 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Jul 2016 16:53:46 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: <20160722045117.GA36651@doctor.nl2k.ab.ca> Message-ID: On Fri, 22 Jul 2016, Darren Tucker wrote: > On Fri, Jul 22, 2016 at 2:51 PM, The Doctor wrote: > > On Fri, Jul 22, 2016 at 02:40:04PM +1000, Damien Miller wrote: > [...] > >> OpenSSH 5.3 is almost ready for release, so we would appreciate testing > > ^ > > Huh? > > Either a clone of Damien has been frozen Austin Powers style since > 2009 and has only just been thawed out or maybe it was a typo. Tough > to tell. More like Encino Man From doctor at doctor.nl2k.ab.ca Fri Jul 22 17:35:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 22 Jul 2016 01:35:27 -0600 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: <20160722045117.GA36651@doctor.nl2k.ab.ca> Message-ID: <20160722073527.GA15131@doctor.nl2k.ab.ca> On Fri, Jul 22, 2016 at 04:53:46PM +1000, Damien Miller wrote: > On Fri, 22 Jul 2016, Darren Tucker wrote: > > > On Fri, Jul 22, 2016 at 2:51 PM, The Doctor wrote: > > > On Fri, Jul 22, 2016 at 02:40:04PM +1000, Damien Miller wrote: > > [...] > > >> OpenSSH 5.3 is almost ready for release, so we would appreciate testing > > > ^ > > > Huh? > > > > Either a clone of Damien has been frozen Austin Powers style since > > 2009 and has only just been thawed out or maybe it was a typo. Tough > > to tell. > > More like Encino Man FreeBSD 10.3 amd64 Openssl 1.0.2i-dev checks out no problem What is happening to openssl 1.1 suppolrt? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Language is the source of misunderstandings. -Antoine de Saint-Exupery From djm at mindrot.org Fri Jul 22 17:44:15 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Jul 2016 17:44:15 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722073527.GA15131@doctor.nl2k.ab.ca> References: <20160722045117.GA36651@doctor.nl2k.ab.ca> <20160722073527.GA15131@doctor.nl2k.ab.ca> Message-ID: On Fri, 22 Jul 2016, The Doctor wrote: > > More like Encino Man > > FreeBSD 10.3 amd64 Openssl 1.0.2i-dev checks out no problem > > What is happening to openssl 1.1 suppolrt? No progress yet - it's quite a bit of work as they APIs are quite different. I hope to look at it in the next release. -d From coredump at autistici.org Fri Jul 22 19:05:09 2016 From: coredump at autistici.org (C0r3dump3d) Date: Fri, 22 Jul 2016 11:05:09 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: <475649e7-2c25-0441-e17f-fe5b008f820c@autistici.org> Hi, I have tested the mitigation timing differences in password authentication (CVE-2016-6210). I have compiled openssh-SNAP-20160722.tar.gz in a Debian 8 and use my tool Osueta (https://github.com/c0r3dump3d/osueta) against the system. Ok, I have seen that you calculate all the password hash exist or not exist the user, and with this you can not discriminate the presence or absence of that user, but now it's more easy to establish the DOS condition in the access to the Openssh server and exhausting the CPU resources, any dummy user it can be used! For example: osueta -H 192.168.100.204 -U asdf -v no -d 15 -p 22 --dos yes -t 40 Users found Time delay in seconds -------------------------------------- asdf 27 I have attached screenshots with the CPU resource exhaustion and the DOS in the access to the Openssh server. The test machine it's a Debian 8 VM in KVM with 4 Core and 2GB of RAM. For CVE-2016-6210 user enumeration really it's mitigate but for the problem of DOS as I say seems much easier to exploit!! Regards. Andres Rojas http://www.devconsole.info El 22/07/16 a las 06:40, Damien Miller escribi?: > Hi, > > OpenSSH 5.3 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains some > substantial new features and a number of bugfixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From vinschen at redhat.com Fri Jul 22 20:05:53 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 22 Jul 2016 12:05:53 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: <20160722100553.GA4943@calimero.vinschen.de> On Jul 22 14:40, Damien Miller wrote: > Hi, > > OpenSSH 7.3 is almost ready for release, so we would appreciate testing This version doesn't build on Cygwin anymore. The reason is that various configure tests fail. The culprit is the new definition of IPPORT_RESERVED to 0 in configure.ac. After setting this value in configure, confdefs.h contains #define IPPORT_RESERVED 0 netinet/in.h defines IPPORT_RESERVED as enum, just as on other systems: enum { [...] IPPORT_RESERVED = 1024, [...] }; Since confdefs.h is evaluated *before* including any headers during configure, we have the following situation: #define IPPORT_RESERVED 0 #include --> enum { IPPORT_RESERVED = 1024 }; which evaluates to enum { 0 = 1024 }; which then leads to a compiler error: conftest.c:66:25: error: expected identifier before numeric constant and thus to a broken configuration. The same problem occurs when trying to build the source since config.h is included via includes.h prior to the system headers. So the simplification from NO_IPPORT_RESERVED_CONCEPT to just defining IPPORT_RESERVED as 0 doesn't work as desired. Can we revert this to the former NO_IPPORT_RESERVED_CONCEPT, please? I created the below patch which is less intrusive than the original patch. I tested that it works as desired and OpenSSH 7.3 builds on Cygwin. I have not *tested* OpenSSH7.3 on Cygwin yet. I'll report back in a followup mail. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- From 6fd39268386c130dd0444df761e9e565da47cae5 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Fri, 22 Jul 2016 11:56:52 +0200 Subject: [PATCH] Don't define IPPORT_RESERVED to 0 in configure.ac. This leads to a broken configuration due to compile time errors during a configure run, as well as to build errors afterwards. To wit: #define IPPORT_RESERVED 0 /* #include */ enum { [...] IPPORT_RESERVED = 1024, [...] }; Signed-off-by: Corinna Vinschen --- configure.ac | 5 +++-- readconf.c | 4 ++++ serverloop.c | 4 ++++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 21ef389..2cd6a6f 100644 --- a/configure.ac +++ b/configure.ac @@ -589,8 +589,9 @@ case "$host" in [Define if you want to disable shadow passwords]) AC_DEFINE([NO_X11_UNIX_SOCKETS], [1], [Define if X11 doesn't support AF_UNIX sockets on that system]) - AC_DEFINE([IPPORT_RESERVED], [0], - [Cygwin has no notion of ports only accessible to superusers]) + AC_DEFINE([NO_IPPORT_RESERVED_CONCEPT], [1], + [Define if the concept of ports only accessible to + superusers isn't known]) AC_DEFINE([DISABLE_FD_PASSING], [1], [Define if your platform needs to skip post auth file descriptor passing]) diff --git a/readconf.c b/readconf.c index c177202..f823a63 100644 --- a/readconf.c +++ b/readconf.c @@ -67,6 +67,10 @@ #include "myproposal.h" #include "digest.h" +#ifdef NO_IPPORT_RESERVED_CONCEPT +#define IPPORT_RESERVED 0 +#endif + /* Format of the configuration file: # Configuration data is parsed as follows: diff --git a/serverloop.c b/serverloop.c index 3563e5d..f2c274e 100644 --- a/serverloop.c +++ b/serverloop.c @@ -80,6 +80,10 @@ #include "serverloop.h" #include "ssherr.h" +#ifdef NO_IPPORT_RESERVED_CONCEPT +#define IPPORT_RESERVED 0 +#endif + extern ServerOptions options; /* XXX */ -- 2.5.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dtucker at zip.com.au Fri Jul 22 20:23:07 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Jul 2016 20:23:07 +1000 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <475649e7-2c25-0441-e17f-fe5b008f820c@autistici.org> References: <475649e7-2c25-0441-e17f-fe5b008f820c@autistici.org> Message-ID: On Fri, Jul 22, 2016 at 7:05 PM, C0r3dump3d wrote: > but now it's more easy to establish the DOS > condition in the access to the Openssh server and exhausting the CPU > resources, any dummy user it can be used! The snapshot you're using (openssh-SNAP-20160722.tar.gz) was unfortunately made in the time after the code to cap the password size at 1k was committed to OpenBSD (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth-passwd.c.diff?r1=1.44&r2=1.45) but before it was synced into -Portable (https://anongit.mindrot.org/openssh.git/commit/?id=fcd135c9df440bcd2d5870405ad3311743d78d97). As a result your very large password strings are still making it into crypt(3). Please either grab the code directly from git (you'll need to run "autoreconf" yourself) or try tomorrow's snapshot and retest it. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From hecht at hlrs.de Fri Jul 22 20:33:26 2016 From: hecht at hlrs.de (Martin Hecht) Date: Fri, 22 Jul 2016 12:33:26 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: <189dd10d-187d-95ea-4f1a-39eaea63d8f7@hlrs.de> On 07/22/2016 06:40 AM, Damien Miller wrote: > [...] > * ssh(1), sshd(8): Improve ordering ordering of MAC verification [...] "ordering ordering" seems to be a typo all tests pass on my machines with: - Ubuntu 14.04.4 LTS - Scientific Linux release 6.7 (Carbon) - SUSE Linux Enterprise Server 11 SP3 tested with openssh-SNAP-20160722.tar.gz -------------- 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 vinschen at redhat.com Fri Jul 22 21:34:32 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 22 Jul 2016 13:34:32 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722100553.GA4943@calimero.vinschen.de> References: <20160722100553.GA4943@calimero.vinschen.de> Message-ID: <20160722113432.GB4943@calimero.vinschen.de> On Jul 22 12:05, Corinna Vinschen wrote: > On Jul 22 14:40, Damien Miller wrote: > > Hi, > > > > OpenSSH 7.3 is almost ready for release, so we would appreciate testing > > This version doesn't build on Cygwin anymore. The reason is that > various configure tests fail. > > The culprit is the new definition of IPPORT_RESERVED to 0 in configure.ac. > > After setting this value in configure, confdefs.h contains > > #define IPPORT_RESERVED 0 > > netinet/in.h defines IPPORT_RESERVED as enum, just as on other systems: > > enum > { > [...] > IPPORT_RESERVED = 1024, > [...] > }; > > Since confdefs.h is evaluated *before* including any headers during > configure, we have the following situation: > > #define IPPORT_RESERVED 0 > #include > --> enum { IPPORT_RESERVED = 1024 }; > > which evaluates to > > enum { 0 = 1024 }; > > which then leads to a compiler error: > > conftest.c:66:25: error: expected identifier before numeric constant > > and thus to a broken configuration. > > The same problem occurs when trying to build the source since config.h > is included via includes.h prior to the system headers. > > So the simplification from NO_IPPORT_RESERVED_CONCEPT to just > defining IPPORT_RESERVED as 0 doesn't work as desired. > > Can we revert this to the former NO_IPPORT_RESERVED_CONCEPT, please? > > I created the below patch which is less intrusive than the original > patch. I tested that it works as desired and OpenSSH 7.3 builds > on Cygwin. > > I have not *tested* OpenSSH7.3 on Cygwin yet. I'll report back in a > followup mail. All tests pass on current Cygwin with this patch applied. Thanks, 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 coredump at autistici.org Fri Jul 22 21:40:46 2016 From: coredump at autistici.org (C0r3dump3d) Date: Fri, 22 Jul 2016 13:40:46 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: <475649e7-2c25-0441-e17f-fe5b008f820c@autistici.org> Message-ID: <6cde75a3-7e40-69f0-5a4b-6764e472fe47@autistici.org> Hi, I have tried the git version and now it's Ok, no user enumeration and no DOS!! If it's possible for the credits of the bug please include my partner and me: Andres Rojas -- coredump at autistici.org Javier Nieto -- jnieton at gmail.com Thank you very much El 22/07/16 a las 12:23, Darren Tucker escribi?: > On Fri, Jul 22, 2016 at 7:05 PM, C0r3dump3d wrote: >> but now it's more easy to establish the DOS >> condition in the access to the Openssh server and exhausting the CPU >> resources, any dummy user it can be used! > > The snapshot you're using (openssh-SNAP-20160722.tar.gz) was > unfortunately made in the time after the code to cap the password size > at 1k was committed to OpenBSD > (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth-passwd.c.diff?r1=1.44&r2=1.45) > but before it was synced into -Portable > (https://anongit.mindrot.org/openssh.git/commit/?id=fcd135c9df440bcd2d5870405ad3311743d78d97). > As a result your very large password strings are still making it into > crypt(3). > > Please either grab the code directly from git (you'll need to run > "autoreconf" yourself) or try tomorrow's snapshot and retest it. > From dtucker at zip.com.au Fri Jul 22 21:37:32 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Jul 2016 21:37:32 +1000 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722100553.GA4943@calimero.vinschen.de> References: <20160722100553.GA4943@calimero.vinschen.de> Message-ID: <20160722113732.GA17756@gate.dtucker.net> On Fri, Jul 22, 2016 at 12:05:53PM +0200, Corinna Vinschen wrote: [...] > This version doesn't build on Cygwin anymore. The reason is that > various configure tests fail. > > The culprit is the new definition of IPPORT_RESERVED to 0 in configure.ac. Sigh. How about putting it in defines.h instead? includes.h includes netinet/in.h from whence the definition of IPPORT_RESERVED is, on Cygwin at least, seems to be protected against multiple inclusion. Putting it there means only one definition in a file that we don't sync with OpenBSD. diff --git a/configure.ac b/configure.ac index 21ef389..2cd6a6f 100644 --- a/configure.ac +++ b/configure.ac @@ -589,8 +589,9 @@ case "$host" in [Define if you want to disable shadow passwords]) AC_DEFINE([NO_X11_UNIX_SOCKETS], [1], [Define if X11 doesn't support AF_UNIX sockets on that system]) - AC_DEFINE([IPPORT_RESERVED], [0], - [Cygwin has no notion of ports only accessible to superusers]) + AC_DEFINE([NO_IPPORT_RESERVED_CONCEPT], [1], + [Define if the concept of ports only accessible to + superusers isn't known]) AC_DEFINE([DISABLE_FD_PASSING], [1], [Define if your platform needs to skip post auth file descriptor passing]) diff --git a/defines.h b/defines.h index a438ddd..c099df6 100644 --- a/defines.h +++ b/defines.h @@ -43,6 +43,17 @@ enum #endif /* + * Cygwin doesn't really have a notion of reserved ports but for backward + * compatibility they define it to 1024 in netinet/in.h inside an enum. We + * don't actually want that restriction so we want to set that to zero, but + * we can't do it direct in config.h because it'll cause a conflicting + * definition the first time we include netinet/in.h. + */ +#ifdef NO_IPPORT_RESERVED_CONCEPT +#define IPPORT_RESERVED 0 +#endif + +/* * Definitions for IP type of service (ip_tos) */ #include -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Fri Jul 22 22:18:55 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 22 Jul 2016 14:18:55 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722113732.GA17756@gate.dtucker.net> References: <20160722100553.GA4943@calimero.vinschen.de> <20160722113732.GA17756@gate.dtucker.net> Message-ID: <20160722121855.GA27722@calimero.vinschen.de> On Jul 22 21:37, Darren Tucker wrote: > On Fri, Jul 22, 2016 at 12:05:53PM +0200, Corinna Vinschen wrote: > [...] > > This version doesn't build on Cygwin anymore. The reason is that > > various configure tests fail. > > > > The culprit is the new definition of IPPORT_RESERVED to 0 in configure.ac. > > Sigh. > > How about putting it in defines.h instead? includes.h includes > netinet/in.h from whence the definition of IPPORT_RESERVED is, on Cygwin > at least, seems to be protected against multiple inclusion. Putting it > there means only one definition in a file that we don't sync with OpenBSD. Hmm. If that only affects Cygwin, and if defines.h is not synced anyway, what about getting rid of the configure stuff entirely? Tested counterproposal: diff --git a/configure.ac b/configure.ac index 21ef389..e64386f 100644 --- a/configure.ac +++ b/configure.ac @@ -589,8 +589,6 @@ case "$host" in [Define if you want to disable shadow passwords]) AC_DEFINE([NO_X11_UNIX_SOCKETS], [1], [Define if X11 doesn't support AF_UNIX sockets on that system]) - AC_DEFINE([IPPORT_RESERVED], [0], - [Cygwin has no notion of ports only accessible to superusers]) AC_DEFINE([DISABLE_FD_PASSING], [1], [Define if your platform needs to skip post auth file descriptor passing]) diff --git a/defines.h b/defines.h index a438ddd..d1ad6a7 100644 --- a/defines.h +++ b/defines.h @@ -43,6 +43,17 @@ enum #endif /* + * Cygwin doesn't really have a notion of reserved ports but for backward + * compatibility they define it to 1024 in netinet/in.h inside an enum. We + * don't actually want that restriction so we want to set that to zero, but + * we can't do it direct in config.h because it'll cause a conflicting + * definition the first time we include netinet/in.h. + */ +#ifdef HAVE_CYGWIN +#define IPPORT_RESERVED 0 +#endif + +/* * Definitions for IP type of service (ip_tos) */ #include As for the comment preceeding the definition, I didn't change it from your text in my proposal. However. I'd like to outline that IPPORT_RESERVED == 1024 still makes sense in terms of the implementation of bindresvport_sa and rcmd. It's not just backward compatibility. There are also applications out there which still expect this value to make sense. The *real* problem here is that OpenSSH checks for uid 0 before allowing to bind a socket to a port < IPPORT_RESERVED, rather than letting the OS decide if the current user is allowed to bind that port. From my POV this check in OpenSSH is gratuitious and it's the real reason we have this problem at all. Thanks, 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 dtucker at zip.com.au Fri Jul 22 23:32:51 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 Jul 2016 23:32:51 +1000 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722121855.GA27722@calimero.vinschen.de> References: <20160722100553.GA4943@calimero.vinschen.de> <20160722113732.GA17756@gate.dtucker.net> <20160722121855.GA27722@calimero.vinschen.de> Message-ID: On Fri, Jul 22, 2016 at 10:18 PM, Corinna Vinschen wrote: [...] > Hmm. If that only affects Cygwin, and if defines.h is not synced anyway, > what about getting rid of the configure stuff entirely? > > Tested counterproposal: Looks reasonable. It's late here so I'm going to look at it tomorrow. > As for the comment preceeding the definition, I didn't change it from > your text in my proposal. However. > > I'd like to outline that IPPORT_RESERVED == 1024 still makes sense in > terms of the implementation of bindresvport_sa and rcmd. It's not just > backward compatibility. There are also applications out there which > still expect this value to make sense. Fair point. > The *real* problem here is that OpenSSH checks for uid 0 before allowing > to bind a socket to a port < IPPORT_RESERVED, rather than letting the OS > decide if the current user is allowed to bind that port. > From my POV this check in OpenSSH is gratuitious and it's the real reason > we have this problem at all. In the case of sshd running with privsep off, the process doing the binding is still running as root and I suspect those checks date back to when it was always running as root. It could probably temporarily_use_uid() though. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From htodd at twofifty.com Sat Jul 23 00:58:52 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 22 Jul 2016 07:58:52 -0700 (PDT) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: In NetBSD-current(ish): test_sshkey: ..................................[1] Segmentation fault (core dumped) ${V} /home/htodd... *** Error code 139 And gdb bt shows: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000041174e in cert_parse (key=0x756584f120c0, certbuf=0x756584f16200, b=0x756584f161b0) at sshkey.c:1896 1896 key->cert->principals[key->cert->nprincipals++] = principal; (gdb) bt #0 0x000000000041174e in cert_parse (key=0x756584f120c0, certbuf=0x756584f16200, b=0x756584f161b0) at sshkey.c:1896 #1 sshkey_from_blob_internal (b=b at entry=0x756584f161b0, keyp=keyp at entry=0x7f7fff8c0220, allow_cert=allow_cert at entry=1) at sshkey.c:2117 #2 0x0000000000411951 in sshkey_from_blob (blob=, blen=blen at entry=422, keyp=keyp at entry=0x7f7fff8c0220) at sshkey.c:2150 #3 0x0000000000411a97 in sshkey_read (ret=ret at entry=0x756584f12080, cpp=cpp at entry=0x7f7fff8c0280) at sshkey.c:1302 #4 0x0000000000414baa in sshkey_try_load_public (k=k at entry=0x756584f12080, filename=0x756584f16070 "/home/htodd/openssh-portable/regress/unittests/sshkey/testdata/rsa_1-cert.pub", commentp=commentp at entry=0x0) at authfile.c:319 #5 0x0000000000415309 in sshkey_load_cert (filename=, keyp=keyp at entry=0x7f7fff8c4330) at authfile.c:425 #6 0x0000000000409f41 in sshkey_tests () at regress/unittests/sshkey/test_sshkey.c:527 #7 0x0000000000405dc3 in tests () at regress/unittests/sshkey/tests.c:24 #8 0x000000000042a2e1 in main (argc=3, argv=0x7f7fff8c4420) at regress/unittests/test_helper/test_helper.c:162 (gdb) -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From vinschen at redhat.com Sat Jul 23 02:45:55 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 22 Jul 2016 18:45:55 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: <20160722100553.GA4943@calimero.vinschen.de> <20160722113732.GA17756@gate.dtucker.net> <20160722121855.GA27722@calimero.vinschen.de> Message-ID: <20160722164555.GA30576@calimero.vinschen.de> On Jul 22 23:32, Darren Tucker wrote: > On Fri, Jul 22, 2016 at 10:18 PM, Corinna Vinschen wrote: > [...] > > Hmm. If that only affects Cygwin, and if defines.h is not synced anyway, > > what about getting rid of the configure stuff entirely? > > > > Tested counterproposal: > > Looks reasonable. It's late here so I'm going to look at it tomorrow. Thank you. > > As for the comment preceeding the definition, I didn't change it from > > your text in my proposal. However. > > > > I'd like to outline that IPPORT_RESERVED == 1024 still makes sense in > > terms of the implementation of bindresvport_sa and rcmd. It's not just > > backward compatibility. There are also applications out there which > > still expect this value to make sense. > > Fair point. > > > The *real* problem here is that OpenSSH checks for uid 0 before allowing > > to bind a socket to a port < IPPORT_RESERVED, rather than letting the OS > > decide if the current user is allowed to bind that port. > > From my POV this check in OpenSSH is gratuitious and it's the real reason > > we have this problem at all. > > In the case of sshd running with privsep off, the process doing the > binding is still running as root and I suspect those checks date back > to when it was always running as root. It could probably > temporarily_use_uid() though. I think this is a very good idea. As has been discussed more than once on this list, Cygwin^WWindows isn't the only OS allowing more than a single administrativ account. Alternatively the system supports fine-grained account-based permissions or per-executable capabilities. For example, think raw sockets and ping/ping6. You don't have to be admin to open a raw socket if the OS supports capabilities, nor does the application has to be a setuid application, as on Linux: $ ls -l /usr/bin/ping -rwxr-xr-x 1 root root 44752 Nov 19 2015 /usr/bin/ping $ getcap /usr/bin/ping ping = cap_net_admin,cap_net_raw+ep Checking for uid 0 only makes limited sense, and only on very traditional UNIX systems. 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 htodd at twofifty.com Sat Jul 23 02:44:04 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 22 Jul 2016 09:44:04 -0700 (PDT) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: After making /var/empty, tests ran fine on netbsd-7. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From tin at komna.com Sat Jul 23 04:32:51 2016 From: tin at komna.com (Valentin Kozamernik) Date: Fri, 22 Jul 2016 20:32:51 +0200 Subject: SSH crash on OpenBSD (pledge related?) Message-ID: <20160722183251.GA3612@maximiliano.komna.net> Hello, I just ran upon this problem and couldn't find it in bugzilla. SSH crashes (abort trap) if all of the following conditions are met: (a) option -f is used (crash happens when going to background), (b) reverse port forwarding is set up (option -R), (c) option ExitOnForwardFailure is enabled, (d) there are no actual port-forwarding failures. The problem can be reproduced by running this command: ssh -f -N -R 1234:[::1]:4321 -o ExitOnForwardFailure=yes ::1 Repeatable every time at least on OpenBSD 5.9 and the latest snapshot (July 17th), on amd64/bsd.mp using default installation. Please CC me any replies as I'm not subscribed to this mailing list. Tin -- Valentin Kozamernik Ljubljana, Slovenia Phone: +386 41 35 40 99 PGP: 2D34 9133 0B9D 1EEA 83E7 0298 60B7 D121 5682 2AA9 From james.murphy.debian at gmail.com Sat Jul 23 05:50:22 2016 From: james.murphy.debian at gmail.com (James Murphy) Date: Fri, 22 Jul 2016 14:50:22 -0500 Subject: Multifactor authentication troubles Message-ID: I'm writing a PAM module to do authentication through Signal (as in Open Whisper Systems) [1]. I would like to be able to offer (Public key AND Signal) or (Password AND Signal) for authentication. This suggests setting AuthenticationMethods to publickey,keyboard-interactive:pam password,keyboard-interactive:pam However, when PAM is enabled "password" means "show password prompt, then do PAM", which is a problem because my PAM does Signal auth, not password auth, and the above results in all login attempts failing. Clearly sshd knows how to do password auth without PAM because it works even when PAM is disabled, so I wonder if there is some way to request that "password" does not use PAM even when PAM is enabled? Ideally one could specify something like password:nopam password:builtin Or another solution would be to allow multiple different PAM modules to be called instead of requiring it all to be lumped into /etc/pam.d/sshd. Then one could specify something like PAMFiles /etc/pam.d/sshd* AuthenticationMethods keyboard-interactive:pam:sshd-pass,keyboard-interactive:pam:sshd-signal Does this kind of functionality already exist, and if not would it be feasible to implement? Thank you for your help, James Murphy [1] https://github.com/kb100/signal-authenticator From djm at mindrot.org Sat Jul 23 09:33:12 2016 From: djm at mindrot.org (Damien Miller) Date: Sat, 23 Jul 2016 09:33:12 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Fri, 22 Jul 2016, Hisashi T Fujinaka wrote: > In NetBSD-current(ish): > > test_sshkey: ..................................[1] Segmentation fault (core > dumped) ${V} /home/htodd... > *** Error code 139 > > And gdb bt shows: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x000000000041174e in cert_parse (key=0x756584f120c0, > certbuf=0x756584f16200, b=0x756584f161b0) at sshkey.c:1896 > 1896 key->cert->principals[key->cert->nprincipals++] = > principal; Thanks for reporting this. I don't understand how it could fail at that point. Could you rerun the failing test and see what the values of key, *key, key->cert and *key->cert are? It's possible to run just the sshkey unit test using: ./regress/unittests/sshkey/test_sshkey -d regress/unittests/sshkey/testdata from the top-level directory. -d From djm at mindrot.org Sat Jul 23 10:01:02 2016 From: djm at mindrot.org (Damien Miller) Date: Sat, 23 Jul 2016 10:01:02 +1000 (AEST) Subject: SSH crash on OpenBSD (pledge related?) In-Reply-To: <20160722183251.GA3612@maximiliano.komna.net> References: <20160722183251.GA3612@maximiliano.komna.net> Message-ID: On Fri, 22 Jul 2016, Valentin Kozamernik wrote: > Hello, > > I just ran upon this problem and couldn't find it in bugzilla. > > SSH crashes (abort trap) if all of the following conditions are met: > > (a) option -f is used (crash happens when going to background), > (b) reverse port forwarding is set up (option -R), > (c) option ExitOnForwardFailure is enabled, > (d) there are no actual port-forwarding failures. > > The problem can be reproduced by running this command: > > ssh -f -N -R 1234:[::1]:4321 -o ExitOnForwardFailure=yes ::1 Thanks, I think the following fixes it. diff --git a/clientloop.c b/clientloop.c index 6740964..fe3baa8 100644 --- a/clientloop.c +++ b/clientloop.c @@ -115,6 +115,9 @@ extern int stdin_null_flag; /* Flag indicating that no shell has been requested */ extern int no_shell_flag; +/* Flag indicating that ssh should daemonise after authentication is complete */ +extern int fork_after_authentication_flag; + /* Control socket */ extern int muxserver_sock; /* XXX use mux_client_cleanup() instead */ @@ -1498,7 +1501,7 @@ client_loop(int have_pty, int escape_char_arg, int ssh2_chan_id) debug("Entering interactive session."); if (options.control_master && - ! option_clear_or_none(options.control_path)) { + !option_clear_or_none(options.control_path)) { debug("pledge: id"); if (pledge("stdio rpath wpath cpath unix inet dns recvfd proc exec id tty", NULL) == -1) @@ -1516,7 +1519,8 @@ client_loop(int have_pty, int escape_char_arg, int ssh2_chan_id) NULL) == -1) fatal("%s pledge(): %s", __func__, strerror(errno)); - } else if (! option_clear_or_none(options.proxy_command)) { + } else if (!option_clear_or_none(options.proxy_command) || + fork_after_authentication_flag) { debug("pledge: proc"); if (pledge("stdio cpath unix inet dns proc tty", NULL) == -1) fatal("%s pledge(): %s", __func__, strerror(errno)); From htodd at twofifty.com Sat Jul 23 12:33:37 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 22 Jul 2016 19:33:37 -0700 (PDT) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: I think I forgot to send this to the mailing list too. On Sat, 23 Jul 2016, Damien Miller wrote: On Fri, 22 Jul 2016, Hisashi T Fujinaka wrote: > In NetBSD-current(ish): > > test_sshkey: ..................................[1] Segmentation fault > (core > dumped) ${V} /home/htodd... > *** Error code 139 > > And gdb bt shows: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x000000000041174e in cert_parse (key=0x756584f120c0, > certbuf=0x756584f16200, b=0x756584f161b0) at sshkey.c:1896 > 1896 key->cert->principals[key->cert->nprincipals++] = > principal; Thanks for reporting this. I don't understand how it could fail at that point. Could you rerun the failing test and see what the values of key, *key, key->cert and *key->cert are? It's possible to run just the sshkey unit test using: ./regress/unittests/sshkey/test_sshkey -d regress/unittests/sshkey/testdata from the top-level directory. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000041174e in cert_parse (key=0x7037f9b120c0, certbuf=0x7037f9b16200, b=0x7037f9b161b0) at sshkey.c:1896 1896 key->cert->principals[key->cert->nprincipals++] = principal; (gdb) bt #0 0x000000000041174e in cert_parse (key=0x7037f9b120c0, certbuf=0x7037f9b16200, b=0x7037f9b161b0) at sshkey.c:1896 #1 sshkey_from_blob_internal (b=b at entry=0x7037f9b161b0, keyp=keyp at entry=0x7f7fff104970, allow_cert=allow_cert at entry=1) at sshkey.c:2117 #2 0x0000000000411951 in sshkey_from_blob (blob=, blen=blen at entry=422, keyp=keyp at entry=0x7f7fff104970) at sshkey.c:2150 #3 0x0000000000411a97 in sshkey_read (ret=ret at entry=0x7037f9b12080, cpp=cpp at entry=0x7f7fff1049d0) at sshkey.c:1302 #4 0x0000000000414baa in sshkey_try_load_public (k=k at entry=0x7037f9b12080, filename=0x7037f9b16070 "/home/htodd/openssh-portable/regress/unittests/sshkey/testdata/rsa_1-cert.pub", commentp=commentp at entry=0x0) at authfile.c:319 #5 0x0000000000415309 in sshkey_load_cert (filename=, keyp=keyp at entry=0x7f7fff108a80) at authfile.c:425 #6 0x0000000000409f41 in sshkey_tests () at regress/unittests/sshkey/test_sshkey.c:527 #7 0x0000000000405dc3 in tests () at regress/unittests/sshkey/tests.c:24 #8 0x000000000042a2e1 in main (argc=3, argv=0x7f7fff108b68) at regress/unittests/test_helper/test_helper.c:162 (gdb) p key $1 = (struct sshkey *) 0x7037f9b120c0 (gdb) p key->cert $2 = (struct sshkey_cert *) 0x7037f9b1b080 (gdb) p *key->cert $3 = {certblob = 0x7037f9b162a0, type = 2, serial = 5, key_id = 0x7037f9b18090 "julius", nprincipals = 1, principals = 0xfffffffff9b180a0, valid_after = 915145200, valid_before = 1293836400, critical = 0x7037f9b162f0, extensions = 0x7037f9b16340, signature_key = 0x0} -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From djm at mindrot.org Sat Jul 23 13:13:24 2016 From: djm at mindrot.org (Damien Miller) Date: Sat, 23 Jul 2016 13:13:24 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Fri, 22 Jul 2016, Hisashi T Fujinaka wrote: > regress/unittests/test_helper/test_helper.c:162 > (gdb) p key > $1 = (struct sshkey *) 0x7037f9b120c0 > (gdb) p key->cert > $2 = (struct sshkey_cert *) 0x7037f9b1b080 > (gdb) p *key->cert > $3 = {certblob = 0x7037f9b162a0, type = 2, serial = 5, key_id = 0x7037f9b18090 > "julius", nprincipals = 1, > principals = 0xfffffffff9b180a0, valid_after = 915145200, valid_before = Thanks for taking the time to debug this. The key->cert->principals pointer looks wrong - does NetBSD libc provide a reallocarray function? We detect its presence during configure: checking for reallocarray... no (that's on Linux) Could you try commenting out the HAVE_REALLOCARRAY line in config.h make clean, make and rerun the test? -d From htodd at twofifty.com Sat Jul 23 14:30:00 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 22 Jul 2016 21:30:00 -0700 (PDT) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Sat, 23 Jul 2016, Damien Miller wrote: > On Fri, 22 Jul 2016, Hisashi T Fujinaka wrote: > >> regress/unittests/test_helper/test_helper.c:162 >> (gdb) p key >> $1 = (struct sshkey *) 0x7037f9b120c0 >> (gdb) p key->cert >> $2 = (struct sshkey_cert *) 0x7037f9b1b080 >> (gdb) p *key->cert >> $3 = {certblob = 0x7037f9b162a0, type = 2, serial = 5, key_id = 0x7037f9b18090 >> "julius", nprincipals = 1, >> principals = 0xfffffffff9b180a0, valid_after = 915145200, valid_before = > > Thanks for taking the time to debug this. > > The key->cert->principals pointer looks wrong - does NetBSD libc > provide a reallocarray function? We detect its presence during > configure: > > checking for reallocarray... no > > (that's on Linux) > > Could you try commenting out the HAVE_REALLOCARRAY line in config.h > make clean, make and rerun the test? That works. Weird how I need that on -current but not on -7. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From dtucker at zip.com.au Sat Jul 23 16:05:24 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Jul 2016 16:05:24 +1000 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Sat, Jul 23, 2016 at 2:30 PM, Hisashi T Fujinaka wrote: [...] >> Could you try commenting out the HAVE_REALLOCARRAY line in config.h >> make clean, make and rerun the test? > > That works. Weird how I need that on -current but not on -7. Looks like reallocarray was added after 7: it's in http://netbsd.gw.com/cgi-bin/man-cgi?reallocarray++NetBSD-current but it's not in http://netbsd.gw.com/cgi-bin/man-cgi?reallocarray++NetBSD-7.0.1. Maybe there's a bug in it? I note that the man page says the prototype needs "_OPENBSD_SOURCE", maybe the lack of prototype gets the return truncated to int? maybe try ./configure --with-cflags=-D_OPENBSD_SOURCE ? -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tin at komna.com Sat Jul 23 18:14:05 2016 From: tin at komna.com (Valentin Kozamernik) Date: Sat, 23 Jul 2016 10:14:05 +0200 Subject: SSH crash on OpenBSD (pledge related?) In-Reply-To: References: <20160722183251.GA3612@maximiliano.komna.net> Message-ID: <20160723081405.GA19852@maximiliano.komna.net> On Sat, 23 Jul 2016 at 10:01, Damien Miller wrote: > Thanks, I think the following fixes it. > > diff --git a/clientloop.c b/clientloop.c Yes, works fine for me with this diff applied. Thank you. Tin -- Valentin Kozamernik Ljubljana, Slovenia Phone: +386 41 35 40 99 PGP: 2D34 9133 0B9D 1EEA 83E7 0298 60B7 D121 5682 2AA9 From dtucker at zip.com.au Sat Jul 23 19:58:38 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Jul 2016 19:58:38 +1000 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <20160722164555.GA30576@calimero.vinschen.de> References: <20160722100553.GA4943@calimero.vinschen.de> <20160722113732.GA17756@gate.dtucker.net> <20160722121855.GA27722@calimero.vinschen.de> <20160722164555.GA30576@calimero.vinschen.de> Message-ID: On Sat, Jul 23, 2016 at 2:45 AM, Corinna Vinschen wrote: > On Jul 22 23:32, Darren Tucker wrote: >> On Fri, Jul 22, 2016 at 10:18 PM, Corinna Vinschen wrote: >> [...] >> > Hmm. If that only affects Cygwin, and if defines.h is not synced anyway, >> > what about getting rid of the configure stuff entirely? >> > >> > Tested counterproposal: I've committed this. I'll look at the other changes after the release. [...] > As has been discussed more than once on this list, Cygwin^WWindows isn't > the only OS allowing more than a single administrativ account. > Alternatively the system supports fine-grained account-based permissions > or per-executable capabilities. Agreed, capabilities is what I was thinking of when I replied. [...] > Checking for uid 0 only makes limited sense, and only on very > traditional UNIX systems. In its defense, I suspect that's all it ran on at the time it was written. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Sat Jul 23 20:25:23 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 23 Jul 2016 12:25:23 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: <20160722100553.GA4943@calimero.vinschen.de> <20160722113732.GA17756@gate.dtucker.net> <20160722121855.GA27722@calimero.vinschen.de> <20160722164555.GA30576@calimero.vinschen.de> Message-ID: <20160723102523.GB11373@calimero.vinschen.de> On Jul 23 19:58, Darren Tucker wrote: > On Sat, Jul 23, 2016 at 2:45 AM, Corinna Vinschen wrote: > > On Jul 22 23:32, Darren Tucker wrote: > >> On Fri, Jul 22, 2016 at 10:18 PM, Corinna Vinschen wrote: > >> [...] > >> > Hmm. If that only affects Cygwin, and if defines.h is not synced anyway, > >> > what about getting rid of the configure stuff entirely? > >> > > >> > Tested counterproposal: > > I've committed this. > > I'll look at the other changes after the release. > > [...] > > As has been discussed more than once on this list, Cygwin^WWindows isn't > > the only OS allowing more than a single administrativ account. > > Alternatively the system supports fine-grained account-based permissions > > or per-executable capabilities. > > Agreed, capabilities is what I was thinking of when I replied. > > [...] > > Checking for uid 0 only makes limited sense, and only on very > > traditional UNIX systems. > > In its defense, I suspect that's all it ran on at the time it was written. :) Which is quite a long time ago. The big problem with a patch replacing the uid == 0 checks is probably that it has to be accepted upstream... 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 dtucker at zip.com.au Sun Jul 24 08:53:25 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 Jul 2016 08:53:25 +1000 Subject: Multifactor authentication troubles In-Reply-To: References: Message-ID: On Sat, Jul 23, 2016 at 5:50 AM, James Murphy wrote: > I'm writing a PAM module to do authentication through Signal (as in Open > Whisper Systems) [1]. I would like to be able to offer > (Public key AND Signal) or (Password AND Signal) > > for authentication. This suggests setting AuthenticationMethods to > publickey,keyboard-interactive:pam password,keyboard-interactive:pam > > However, when PAM is enabled "password" means "show password prompt, > then do PAM", which is a problem because my PAM does Signal auth, not > password auth, The PAM conversation is whatever you configure the stack to be, not just one of password or Signal. For example you could have this in your PAM ssh config: auth required pam_unix.so auth requred pam_signal.so and as long as you're using SSH Protocol 2, it should allow multiple conversations in a single call to pam_authenticate. That should get you the "password then Signal" authentication via only keyboard-interactive. [...] > Or another solution would be to allow multiple different PAM modules to > be called instead of requiring it all to be lumped into /etc/pam.d/sshd. There's an open enhancement request for this: https://bugzilla.mindrot.org/show_bug.cgi?id=2246 > Then one could specify something like > > PAMFiles /etc/pam.d/sshd* > AuthenticationMethods > keyboard-interactive:pam:sshd-pass,keyboard-interactive:pam:sshd-signal You can get this behaviour by putting both auth modules in the ssh stack config as described above and that should work with the current production code. Getting (Public key AND Signal) or (Password AND Signal) to work is trickier. I can imagine 2 ways to do it, both of which require changes not in the current production code. 1) Use the per-auth-type PAM configs as per https://bugzilla.mindrot.org/show_bug.cgi?id=2246. 2) Configure the ssh-passwd stack to have just pam_unix.so and the ssh-kbdint stack to have just pam_signal.so. 3) Put "AuthenticationMethods password,keyboard-interactive publickey,keyboard-interactive" into sshd_config. sshd should offer you either of publickey or password first then proceed to keyboard-interactive. OR (and this one is fuzzier) a) Use "expose authentication information to PAM" as per https://bugzilla.mindrot.org/show_bug.cgi?id=2408 b) Put "AuthenticationMethods "publickey,keyboard-interactive keyboard-interactive" in sshd_config c) Put both pam_unix.so and pam_signal.so in the PAM config and have it somehow check for the indication that pubkey has been successful and if found, skip pam_unix somehow. I don't know of a way to do that offhand though. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From james.murphy.debian at gmail.com Sun Jul 24 09:49:17 2016 From: james.murphy.debian at gmail.com (James Murphy) Date: Sat, 23 Jul 2016 18:49:17 -0500 Subject: Multifactor authentication troubles In-Reply-To: References: Message-ID: <95510032-62ec-be9d-b4b2-dc59d54291cc@gmail.com> On 07/23/2016 05:53 PM, Darren Tucker wrote: > 1) Use the per-auth-type PAM configs as per > https://bugzilla.mindrot.org/show_bug.cgi?id=2246. > 2) Configure the ssh-passwd stack to have just pam_unix.so and the > ssh-kbdint stack to have just pam_signal.so. > 3) Put "AuthenticationMethods password,keyboard-interactive > publickey,keyboard-interactive" into sshd_config. This seems to be exactly what I'm looking for. I see that a patch was written on 2015-04-16 that implements this functionality, though there has been no action taken or feedback given on the patch since then. Has this slipped through the cracks, or were there more issues that needed to be resolved before merging? James Murphy From djm at mindrot.org Sun Jul 24 21:48:01 2016 From: djm at mindrot.org (Damien Miller) Date: Sun, 24 Jul 2016 21:48:01 +1000 (AEST) Subject: Multifactor authentication troubles In-Reply-To: <95510032-62ec-be9d-b4b2-dc59d54291cc@gmail.com> References: <95510032-62ec-be9d-b4b2-dc59d54291cc@gmail.com> Message-ID: On Sat, 23 Jul 2016, James Murphy wrote: > On 07/23/2016 05:53 PM, Darren Tucker wrote: > > 1) Use the per-auth-type PAM configs as per > > https://bugzilla.mindrot.org/show_bug.cgi?id=2246. > > 2) Configure the ssh-passwd stack to have just pam_unix.so and the > > ssh-kbdint stack to have just pam_signal.so. > > 3) Put "AuthenticationMethods password,keyboard-interactive > > publickey,keyboard-interactive" into sshd_config. > > This seems to be exactly what I'm looking for. I see that a patch was > written on 2015-04-16 that implements this functionality, though there > has been no action taken or feedback given on the patch since then. Has > this slipped through the cracks, or were there more issues that needed > to be resolved before merging? Probably a bit of both :/ -d From nunojpg at gmail.com Mon Jul 25 16:56:01 2016 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Mon, 25 Jul 2016 08:56:01 +0200 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: Hi Alon, I confirmed with pkcs11-tool (from OpenSC) and I can confirm that pressing return when asked for the pin causes the login to stop (and not to try a empty pin). Can you confirm if a empty pin is actually a valid pin, and if not, can the patch be accepted? Once again, the problem is that from a user experience, *some/most* users would expect they can skip pkcs11 token authentication just by pressing return and trying then other authentication method, like password. But currently that is not what happens, and users can find out too late that they have instead tried a wrong pin too many times and locked their token... Regards, Nuno On Fri, Jun 17, 2016 at 10:04 PM, Alon Bar-Lev wrote: > On 17 June 2016 at 22:45, Nuno Gon?alves wrote: >> On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev wrote: >>> On 17 June 2016 at 20:58, Nuno Gon?alves wrote: >>>> Hi, >>>> >>>> It seems there is a bug with the pkcs11 feature where a zero-length >>>> PIN is accepted. I believe this is a bug, since the user might want to >>>> press return when asked for the PIN to ignore that slot/key. >>> >>> Hi, >>> >>> Empty PIN is valid case, not sure why you want to avoid supporting it. >>> >>> Alon >> >> I didn't know it was valid but the reasoning still applies. I don't >> really know the standard use cases, but I think it could eventually be >> useful for the user, when asked for the PIN, to decide not enter it. >> Currently it can only be done by killing ssh. If empty PIN is valid, >> but eventually not usual, maybe we should ask if the user really wants >> to try a empty pin or just continue to another authentication option? > > Not sure what best solution, but ignoring empty PIN is the same as > ignoring "cancel" or similar constants, which is more explicit. > What's wrong with plain -C, as without PIN there is no use to > continue session anyway. > >> Regarding the CKF_USER_PIN flags, do you think it is a good idea to >> implement the warning messages? > > Most implementations do not support these. > > Regards, > Alon From alon.barlev at gmail.com Mon Jul 25 17:38:33 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 25 Jul 2016 10:38:33 +0300 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: Hi, I am not the maintainer of openssh pkcs11 module, so I cannot accept anything :) However, I do believe that empty PIN is a valid PIN in PKCS#11 spec. Regards, Alon On 25 July 2016 at 09:56, Nuno Gon?alves wrote: > > Hi Alon, > > I confirmed with pkcs11-tool (from OpenSC) and I can confirm that > pressing return when asked for the pin causes the login to stop (and > not to try a empty pin). > > Can you confirm if a empty pin is actually a valid pin, and if not, > can the patch be accepted? > > Once again, the problem is that from a user experience, *some/most* > users would expect they can skip pkcs11 token authentication just by > pressing return and trying then other authentication method, like > password. > > But currently that is not what happens, and users can find out too > late that they have instead tried a wrong pin too many times and > locked their token... > > Regards, > Nuno > > On Fri, Jun 17, 2016 at 10:04 PM, Alon Bar-Lev wrote: > > On 17 June 2016 at 22:45, Nuno Gon?alves wrote: > >> On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev wrote: > >>> On 17 June 2016 at 20:58, Nuno Gon?alves wrote: > >>>> Hi, > >>>> > >>>> It seems there is a bug with the pkcs11 feature where a zero-length > >>>> PIN is accepted. I believe this is a bug, since the user might want to > >>>> press return when asked for the PIN to ignore that slot/key. > >>> > >>> Hi, > >>> > >>> Empty PIN is valid case, not sure why you want to avoid supporting it. > >>> > >>> Alon > >> > >> I didn't know it was valid but the reasoning still applies. I don't > >> really know the standard use cases, but I think it could eventually be > >> useful for the user, when asked for the PIN, to decide not enter it. > >> Currently it can only be done by killing ssh. If empty PIN is valid, > >> but eventually not usual, maybe we should ask if the user really wants > >> to try a empty pin or just continue to another authentication option? > > > > Not sure what best solution, but ignoring empty PIN is the same as > > ignoring "cancel" or similar constants, which is more explicit. > > What's wrong with plain -C, as without PIN there is no use to > > continue session anyway. > > > >> Regarding the CKF_USER_PIN flags, do you think it is a good idea to > >> implement the warning messages? > > > > Most implementations do not support these. > > > > Regards, > > Alon From jjelen at redhat.com Mon Jul 25 21:22:29 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 25 Jul 2016 13:22:29 +0200 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: On 07/25/2016 09:38 AM, Alon Bar-Lev wrote: > Hi, > > I am not the maintainer of openssh pkcs11 module, so I cannot accept anything :) > > However, I do believe that empty PIN is a valid PIN in PKCS#11 spec. PKCS#11 tokens provide ulMinPinLen and ulMaxPinLen fields. So the enforced length is token-specific [1] and nothing what would be enforced by the specification. [1] http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf > On 25 July 2016 at 09:56, Nuno Gon?alves wrote: >> Hi Alon, >> >> I confirmed with pkcs11-tool (from OpenSC) and I can confirm that >> pressing return when asked for the pin causes the login to stop (and >> not to try a empty pin). >> >> Can you confirm if a empty pin is actually a valid pin, and if not, >> can the patch be accepted? >> >> Once again, the problem is that from a user experience, *some/most* >> users would expect they can skip pkcs11 token authentication just by >> pressing return and trying then other authentication method, like >> password. >> >> But currently that is not what happens, and users can find out too >> late that they have instead tried a wrong pin too many times and >> locked their token... >> >> Regards, >> Nuno >> >> On Fri, Jun 17, 2016 at 10:04 PM, Alon Bar-Lev wrote: >>> On 17 June 2016 at 22:45, Nuno Gon?alves wrote: >>>> On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev wrote: >>>>> On 17 June 2016 at 20:58, Nuno Gon?alves wrote: >>>>>> Hi, >>>>>> >>>>>> It seems there is a bug with the pkcs11 feature where a zero-length >>>>>> PIN is accepted. I believe this is a bug, since the user might want to >>>>>> press return when asked for the PIN to ignore that slot/key. >>>>> Hi, >>>>> >>>>> Empty PIN is valid case, not sure why you want to avoid supporting it. >>>>> >>>>> Alon >>>> I didn't know it was valid but the reasoning still applies. I don't >>>> really know the standard use cases, but I think it could eventually be >>>> useful for the user, when asked for the PIN, to decide not enter it. >>>> Currently it can only be done by killing ssh. If empty PIN is valid, >>>> but eventually not usual, maybe we should ask if the user really wants >>>> to try a empty pin or just continue to another authentication option? >>> Not sure what best solution, but ignoring empty PIN is the same as >>> ignoring "cancel" or similar constants, which is more explicit. >>> What's wrong with plain -C, as without PIN there is no use to >>> continue session anyway. >>> >>>> Regarding the CKF_USER_PIN flags, do you think it is a good idea to >>>> implement the warning messages? >>> Most implementations do not support these. >>> >>> Regards, >>> Alon > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From alex at cooperi.net Tue Jul 26 06:22:18 2016 From: alex at cooperi.net (Alex Wilson) Date: Mon, 25 Jul 2016 13:22:18 -0700 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On 7/21/16 9:40 PM, Damien Miller wrote: > Live testing on suitable non-production systems is also > appreciated. Working fine on illumos here. The GSSAPI key exchange patch we've been carrying around for compat needs some work now though (or maybe we'll just drop it). From mahodardev at gmail.com Tue Jul 26 14:03:48 2016 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Tue, 26 Jul 2016 16:03:48 +1200 Subject: Question about Zeroise sensitive data on client exit on server side. Message-ID: Hi, I was trying to understand the Zeroise process for ssh server when a client leaves due to connection close, or time out and other cases. And, I noticed that when the client leave the following function on the server cleanup_exit will get called. >From my understanding this function will close all the user authentication related things and then will exit the server process forked for that client connection. I added some debug to ssh_packet_close function, but I cloud not see this being hit in this case. So, just out of interest I would like to know why the sensitive information on the server side is not zeroised. Cause I can see the ssh_packet_close was getting hit on the client side. Thanks, Mahoda From jjelen at redhat.com Wed Jul 27 00:18:55 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 26 Jul 2016 16:18:55 +0200 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: <8fe0485a-c46d-da56-b8a5-0bed1b718b24@redhat.com> On 07/22/2016 06:40 AM, Damien Miller wrote: > OpenSSH 5.3 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains some > substantial new features and a number of bugfixes. Testing with latest snap/git and applying our patches revealed only one problem (when I don't count missing API for GSSAPI Kex, where we were using get_canonical_hostname() also in the client code): * Forgotten get_remote_ipaddr() function in audit-linux.c code (attached patch) Otherwise the package builds and passes all tests on current Fedora 24. Regards, -- Jakub Jelen Security Technologies Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-ssh-remote-ipaddr.patch Type: text/x-patch Size: 603 bytes Desc: not available URL: From djm at mindrot.org Wed Jul 27 08:26:17 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Jul 2016 08:26:17 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: <8fe0485a-c46d-da56-b8a5-0bed1b718b24@redhat.com> References: <8fe0485a-c46d-da56-b8a5-0bed1b718b24@redhat.com> Message-ID: On Tue, 26 Jul 2016, Jakub Jelen wrote: > On 07/22/2016 06:40 AM, Damien Miller wrote: > > OpenSSH 5.3 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This release contains some > > substantial new features and a number of bugfixes. > Testing with latest snap/git and applying our patches revealed only one > problem (when I don't count missing API for GSSAPI Kex, where we were using > get_canonical_hostname() also in the client code): > > * Forgotten get_remote_ipaddr() function in audit-linux.c code (attached > patch) Applied (also needed to include packet.h). -d From vincent.brillault at cern.ch Wed Jul 27 16:49:29 2016 From: vincent.brillault at cern.ch (Vincent Brillault) Date: Wed, 27 Jul 2016 08:49:29 +0200 Subject: Multifactor authentication troubles In-Reply-To: References: Message-ID: <20160727064929.GF1414@Fea.lerya.net> Dear Darren, James, > 1) Use the per-auth-type PAM configs as per > https://bugzilla.mindrot.org/show_bug.cgi?id=2246. > 2) Configure the ssh-passwd stack to have just pam_unix.so and the > ssh-kbdint stack to have just pam_signal.so. > 3) Put "AuthenticationMethods password,keyboard-interactive > publickey,keyboard-interactive" into sshd_config. > > sshd should offer you either of publickey or password first then > proceed to keyboard-interactive. One downside of such an approach is that "password", as far as I understand, has less feature than "keyboard-interactive:pam". For example, it does not support "password change": if you are want to be able to force your users to change their password on the next successful logins, that won't work with "password". > OR (and this one is fuzzier) What do you mean by "fuzzier"? It looks simpler to me ;) Full disclosure: I'm one of the author of that patch > a) Use "expose authentication information to PAM" as per > https://bugzilla.mindrot.org/show_bug.cgi?id=2408 > b) Put "AuthenticationMethods "publickey,keyboard-interactive > keyboard-interactive" in sshd_config > c) Put both pam_unix.so and pam_signal.so in the PAM config and have > it somehow check for the indication that pubkey has been successful > and if found, skip pam_unix somehow. I don't know of a way to do that > offhand though. You need a small pam module for that, for example https://github.com/CERN-CERT/pam_2fa/blob/master/pam_ssh_user_auth.c For more details on how to use that patch: https://cern-cert.github.io/pam_2fa/#using-a-smart-pam-configuration (The rest of that page explains why we think we need that patch) A small additional benefit of that patch is that pam will have more information on what made the first factor succeed and can be then used to learn "who connected as root" (shared account) and match this information to the corresponding 2nd factor (valid for that particular account and not simply any user allowed to login with that account). Cheers, Vincent -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From djm at mindrot.org Wed Jul 27 17:28:16 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Jul 2016 17:28:16 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Sat, 23 Jul 2016, Darren Tucker wrote: > [...] > >> Could you try commenting out the HAVE_REALLOCARRAY line in config.h > >> make clean, make and rerun the test? > > > > That works. Weird how I need that on -current but not on -7. > > Looks like reallocarray was added after 7: it's in > http://netbsd.gw.com/cgi-bin/man-cgi?reallocarray++NetBSD-current but > it's not in http://netbsd.gw.com/cgi-bin/man-cgi?reallocarray++NetBSD-7.0.1. > Maybe there's a bug in it? I note that the man page says the > prototype needs "_OPENBSD_SOURCE", maybe the lack of prototype gets > the return truncated to int? maybe try ./configure > --with-cflags=-D_OPENBSD_SOURCE ? This is probably the problem - the weird pointer I noted in Fujinaka-san's gdb output was probably a sign-extended integer. Could you try this patch? You'll need to make clean, run autoreconf and configure again. -d diff --git a/configure.ac b/configure.ac index e64386f..373d21b 100644 --- a/configure.ac +++ b/configure.ac @@ -839,6 +839,7 @@ mips-sony-bsd|mips-sony-newsos4) if test "x$withval" != "xno" ; then need_dash_r=1 fi + CPPFLAGS="$CPPFLAGS -D_OPENBSD_SOURCE" AC_DEFINE([SSH_TUN_FREEBSD], [1], [Open tunnel devices the FreeBSD way]) AC_CHECK_HEADER([net/if_tap.h], , AC_DEFINE([SSH_TUN_NO_L2], [1], [No layer 2 tunnel support])) From deengert at gmail.com Thu Jul 28 00:26:00 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 27 Jul 2016 09:26:00 -0500 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: <2ee23d36-5c59-1795-29ed-d447f808a8c4@gmail.com> On 7/25/2016 1:56 AM, Nuno Gon?alves wrote: > Hi Alon, > > I confirmed with pkcs11-tool (from OpenSC) and I can confirm that > pressing return when asked for the pin causes the login to stop (and > not to try a empty pin). > > Can you confirm if a empty pin is actually a valid pin, and if not, > can the patch be accepted? By Empty pin do you mean pPin != NULL && ulPinLen = 0 or do you mean pPin == NULL? If the card supports CKF_PROTECTED_AUTHENTICATION_PATH (may have a pin pad reader) , the a call to C_Login with pPin = NULL wil use the pin pad reader. Without CKF_PROTECTED_AUTHENTICATION_PATH I would find it strange if a card would allow a zero length pin. If no pin is needed a C_Login would not be required either the CKS_RO_PUBLIC_SESSION would work and the key one wants to use does not require PIN protection. (Does SSH check if the key requires the PIN?) What return code does C_Login return if you try and use an "empty pin"? > > Once again, the problem is that from a user experience, *some/most* > users would expect they can skip pkcs11 token authentication just by > pressing return and trying then other authentication method, like > password. > > But currently that is not what happens, and users can find out too > late that they have instead tried a wrong pin too many times and > locked their token... > > Regards, > Nuno > > On Fri, Jun 17, 2016 at 10:04 PM, Alon Bar-Lev wrote: >> On 17 June 2016 at 22:45, Nuno Gon?alves wrote: >>> On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev wrote: >>>> On 17 June 2016 at 20:58, Nuno Gon?alves wrote: >>>>> Hi, >>>>> >>>>> It seems there is a bug with the pkcs11 feature where a zero-length >>>>> PIN is accepted. I believe this is a bug, since the user might want to >>>>> press return when asked for the PIN to ignore that slot/key. >>>> Hi, >>>> >>>> Empty PIN is valid case, not sure why you want to avoid supporting it. >>>> >>>> Alon >>> I didn't know it was valid but the reasoning still applies. I don't >>> really know the standard use cases, but I think it could eventually be >>> useful for the user, when asked for the PIN, to decide not enter it. >>> Currently it can only be done by killing ssh. If empty PIN is valid, >>> but eventually not usual, maybe we should ask if the user really wants >>> to try a empty pin or just continue to another authentication option? >> Not sure what best solution, but ignoring empty PIN is the same as >> ignoring "cancel" or similar constants, which is more explicit. >> What's wrong with plain -C, as without PIN there is no use to >> continue session anyway. >> >>> Regarding the CKF_USER_PIN flags, do you think it is a good idea to >>> implement the warning messages? >> Most implementations do not support these. >> >> Regards, >> Alon > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert From htodd at twofifty.com Thu Jul 28 00:34:56 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Wed, 27 Jul 2016 07:34:56 -0700 (PDT) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Wed, 27 Jul 2016, Damien Miller wrote: > On Sat, 23 Jul 2016, Darren Tucker wrote: > >> [...] >>>> Could you try commenting out the HAVE_REALLOCARRAY line in config.h >>>> make clean, make and rerun the test? >>> >>> That works. Weird how I need that on -current but not on -7. >> >> Looks like reallocarray was added after 7: it's in >> http://netbsd.gw.com/cgi-bin/man-cgi?reallocarray++NetBSD-current but >> it's not in http://netbsd.gw.com/cgi-bin/man-cgi?reallocarray++NetBSD-7.0.1. >> Maybe there's a bug in it? I note that the man page says the >> prototype needs "_OPENBSD_SOURCE", maybe the lack of prototype gets >> the return truncated to int? maybe try ./configure >> --with-cflags=-D_OPENBSD_SOURCE ? > > This is probably the problem - the weird pointer I noted in > Fujinaka-san's gdb output was probably a sign-extended integer. > > Could you try this patch? You'll need to make clean, run autoreconf > and configure again. > > -d > > diff --git a/configure.ac b/configure.ac > index e64386f..373d21b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -839,6 +839,7 @@ mips-sony-bsd|mips-sony-newsos4) > if test "x$withval" != "xno" ; then > need_dash_r=1 > fi > + CPPFLAGS="$CPPFLAGS -D_OPENBSD_SOURCE" > AC_DEFINE([SSH_TUN_FREEBSD], [1], [Open tunnel devices the FreeBSD way]) > AC_CHECK_HEADER([net/if_tap.h], , > AC_DEFINE([SSH_TUN_NO_L2], [1], [No layer 2 tunnel support])) This works. Thanks! -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From mahodardev at gmail.com Thu Jul 28 08:22:19 2016 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Thu, 28 Jul 2016 10:22:19 +1200 Subject: Question about Calling packet_close from cleanup_exitfunction Message-ID: Hi, Just out of interest, is it okay to call packet_close from cleanup_exit function in sshd.c. For a project that I'm working on I need to clear the sensitive information held on the server side before exiting. Thanks, Mahoda From djm at mindrot.org Thu Jul 28 08:56:22 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Jul 2016 08:56:22 +1000 (AEST) Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: On Wed, 27 Jul 2016, Hisashi T Fujinaka wrote: > This works. Thanks! Thanks for your help in debugging this - it's been committed and will be in openssh-7.3. -d From djm at mindrot.org Thu Jul 28 09:08:32 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Jul 2016 09:08:32 +1000 (AEST) Subject: Question about Calling packet_close from cleanup_exitfunction In-Reply-To: References: Message-ID: On Thu, 28 Jul 2016, Mahoda Ratnayaka wrote: > Hi, > > Just out of interest, is it okay to call packet_close from cleanup_exit > function in sshd.c. For a project that I'm working on I need to clear the > sensitive information held on the server side before exiting. It looks like it will be safe if the packet code has been properly initialised AND whatever you are doing doesn't involve threads AND you're not calling it from anything like a signal handler. -d From ethan.rahn at gmail.com Thu Jul 28 11:24:02 2016 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Wed, 27 Jul 2016 18:24:02 -0700 Subject: Openssh-6.6p1 doesn't seem to rekey on the server end Message-ID: Hello, ( note, this is fixed in openssh-7.2p2 ) I was checking that openssh's sshd respected the "RekeyLimit" setting and noticed that it did not seem to respect the setting for blocks ( i.e. RekeyLimit 1K would not rekey ). I examined this a bit and realized that the issue seems to be in monitor.c:monitor_apply_keystate where set_newkeys is called before packet_set_rekey_limits. Since set_newkeys requires packet_set_rekey_limits to set the max blocks value, it results in the requested limits never being set. This is OpenSSH-6.6p1 with patches from Fedora. The patches don't seem to affect this issue. This is also fixed in OpenSSH-7.2p2. I thought it was worth bringing up since I didn't see in any release notes when it got fixed and it was a bit of a head-scratcher. Cheers, Ethan From nunojpg at gmail.com Thu Jul 28 18:25:31 2016 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Thu, 28 Jul 2016 10:25:31 +0200 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: On Mon, Jul 25, 2016 at 1:22 PM, Jakub Jelen wrote: > PKCS#11 tokens provide ulMinPinLen and ulMaxPinLen fields. So the > enforced length is token-specific [1] and nothing what would be enforced by > the specification. Thanks for the info. And do you have any idea if the special case or a 0-length pin is acceptable/used in any application? Thanks, Nuno From lhalbert at reverus.com Sat Jul 30 00:18:26 2016 From: lhalbert at reverus.com (Lucas Halbert) Date: Fri, 29 Jul 2016 14:18:26 +0000 Subject: Openssh AuthorizedKeysCommand Inquiry Message-ID: <936A0A1385D25B4090843DF7CAD19F87070A8013@RevExch.corp.reverus.com> To whom it may concern, I have a question regarding the AuthorizedKeysCommand functionality. Currently I am working on building an openldap sshPublicKey infrastructure which contains sshPublicKey entries with the following format(options keytype base64-encoded-key comment) example: (from="host1.example.com" ssh-rsa AB3Nz...EN8w== user at host1.example.com). I am wondering if the AuthorizedKeysCommand directive, or some other openssh function, offers a facility to parse the "options" field of the sshPublicKey entry in LDAP like openssh does using the authorized_keys file. My goal is to restrict the origin of SSH connections which use key exchange based on the from="" option of the sshPublicKey stored in LDAP. Any guidance you have is appreciated. Thanks, Lucas From lhalbert at reverus.com Sat Jul 30 01:52:00 2016 From: lhalbert at reverus.com (Lucas Halbert) Date: Fri, 29 Jul 2016 15:52:00 +0000 Subject: Openssh AuthorizedKeysCommand Inquiry In-Reply-To: References: <936A0A1385D25B4090843DF7CAD19F87070A8013@RevExch.corp.reverus.com> Message-ID: <936A0A1385D25B4090843DF7CAD19F87070A8653@RevExch.corp.reverus.com> Thank you for your quick response. Everything appears to be working as you described. Keep up the excellent work! Thanks, Lucas -----Original Message----- From: Peter Moody [mailto:peter at hda3.com] Sent: Friday, July 29, 2016 11:33 AM To: Lucas Halbert Cc: openssh-unix-dev at mindrot.org Subject: Re: Openssh AuthorizedKeysCommand Inquiry AuthorizedKeysCommand would point to a script/binary that you write that when run with the configured options, returns what you want the AuthorizedKeysFile to look like for that user. So if you have pubkeys and options stored with your users in ldap in two separate attributes, you should be able to have something like this: # this is in your sshd_config AuthorizedKeysCommand /my/authorized_keys_command %u # and this is the authorized_keys_command script. #!/bin/sh $uid=$1 pubkey=$(ldapsearch uid=$uid sshPubkey| grep -v dn | cut -d ':' -f 2) echo $pubkey On Fri, Jul 29, 2016 at 7:18 AM, Lucas Halbert wrote: > To whom it may concern, > > I have a question regarding the AuthorizedKeysCommand functionality. Currently I am working on building an openldap sshPublicKey infrastructure which contains sshPublicKey entries with the following format(options keytype base64-encoded-key comment) example: (from="host1.example.com" ssh-rsa AB3Nz...EN8w== user at host1.example.com). I am wondering if the AuthorizedKeysCommand directive, or some other openssh function, offers a facility to parse the "options" field of the sshPublicKey entry in LDAP like openssh does using the authorized_keys file. My goal is to restrict the origin of SSH connections which use key exchange based on the from="" option of the sshPublicKey stored in LDAP. Any guidance you have is appreciated. > > Thanks, > Lucas > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From wieland at purdue.edu Sat Jul 30 02:10:24 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Fri, 29 Jul 2016 12:10:24 -0400 Subject: Call for testing: OpenSSH 7.3 In-Reply-To: References: Message-ID: <579B7FF0.103@purdue.edu> Compiles and passes tests on SPARC Solaris 10, using our local build of OpenSSL 1.0.2h. Damien Miller wrote: > Hi, > > OpenSSH 5.3 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains some > substantial new features and a number of bugfixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Git at https://anongit.mindrot.org/openssh.git/ > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the ChangeLog > in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > Changes since OpenSSH 7.2 > ========================= > > This is primarily a bugfix release. > > Security > -------- > > * sshd(8): Mitigate a potential denial-of-service attack against > the system's crypt(3) function via sshd(8). An attacker could > send very long passwords that would cause excessive CPU use in > crypt(3). sshd(8) now refuses to accept password authentication > requests of length greater than 1024 characters. Independently > reported by Tomas Kuthan (Oracle) and curesec via coredump at > autistici.org. > > * sshd(8): Mitigate timing differences in password authentication > that could be used to discern valid from invalid account names > when long passwords were sent and particular password hashing > algorithms are in use on the server. CVE-2016-6210, reported by > EddieEzra.Harari at verint.com > > * ssh(1), sshd(8): Fix observable timing weakness in the CBC padding > oracle countermeasures. Reported by Jean Paul Degabriele, Kenny > Paterson, Torben Hansen and Martin Albrecht. Note that CBC ciphers > are disabled by default and only included for legacy compatibility. > > * ssh(1), sshd(8): Improve ordering ordering of MAC verification for > Encrypt-then-MAC (EtM) mode transport MAC algorithms to verify the > MAC before decrypting any ciphertext. This removes the possibility > of timing differences leaking facts about the plaintext, though no > such leakage has been observed. Reported by Jean Paul Degabriele, > Kenny Paterson, Torben Hansen and Martin Albrecht. > > * sshd(8): (portable only) Ignore PAM environment vars when > UseLogin=yes. If PAM is configured to read user-specified > environment variables and UseLogin=yes in sshd_config, then a > hostile local user may attack /bin/login via LD_PRELOAD or > similar environment variables set via PAM. CVE-2015-8325, > found by Shayan Sadigh. > > New Features > ------------ > > * ssh(1): Add a ProxyJump option and corresponding -J command-line > flag to allow simplified indirection through a one or more SSH > bastions or "jump hosts". > > * ssh(1): Add an IdentityAgent option to allow specifying specific > agent sockets instead of accepting one from the environment. > > * ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be > optionally overridden when using ssh -W. bz#2577 > > * ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as > per draft-sgtatham-secsh-iutf8-00. > > * ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman > 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. > > * ssh-keygen(1), ssh(1), sshd(8): support SHA256 and SHA512 RSA > signatures in certificates; > > * ssh(1): Add an Include directive for ssh_config(5) files. > > * ssh(1): Permit UTF-8 characters in pre-authentication banners sent > from the server. bz#2058 > > Bugfixes > -------- > > * ssh(1), sshd(8): Reduce the syslog level of some relatively common > protocol events from LOG_CRIT. bz#2585 > > * sshd(8): Refuse AuthenticationMethods="" in configurations and > accept AuthenticationMethods=any for the default behaviour of not > requiring multiple authentication. bz#2398 > > * sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN > ATTEMPT!" message when forward and reverse DNS don't match. bz#2585 > > * ssh(1): Close ControlPersist background process stderr except > in debug mode or when logging to syslog. bz#1988 > > * misc: Make PROTOCOL description for direct-streamlocal at openssh.com > channel open messages match deployed code. bz#2529 > > * ssh(1): Deduplicate LocalForward and RemoteForward entries to fix > failures when both ExitOnForwardFailure and hostname > canonicalisation are enabled. bz#2562 > > * sshd(8): Remove fallback from moduli to obsolete "primes" file > that was deprecated in 2001. bz#2559. > > * sshd_config(5): Correct description of UseDNS: it affects ssh > hostname processing for authorized_keys, not known_hosts; bz#2554 > > * ssh(1): Fix authentication using lone certificate keys in an agent > without corresponding private keys on the filesystem. bz#2550 > > * sshd(8): Send ClientAliveInterval pings when a time-based > RekeyLimit is set; previously keepalive packets were not being > sent. bz#2252 > > Portability > ----------- > > * ssh(1), sshd(8): Fix compilation by automatically disabling ciphers > not supported by OpenSSL. bz#2466 > > * misc: Fix compilation failures on some versions of AIX's compiler > related to the definition of the VA_COPY macro. bz#2589 > > * sshd(8): Whitelist more architectures to enable the seccomp-bpf > sandbox. bz#2590 > > * ssh-agent(1), sftp-server(8): Disable process tracing on Solaris > using setpflags(__PROC_PROTECT, ...). bz#2584 > > * sshd(8): On Solaris, don't call Solaris setproject() with > UsePAM=yes it's PAM's responsibility. bz#2425 > > 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. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- 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 thomas at glanzmann.de Sun Jul 31 21:36:54 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Sun, 31 Jul 2016 13:36:54 +0200 Subject: Using -W with -L (Local Forwarding) and -D (Socks Forwarding) Message-ID: <20160731113654.GB27172@glanzmann.de> Hello, I have in my ssh config: Match host 2.3.4.5 exec "~/bin/connect.sh" ProxyCommand ssh -D 1080 -L8080:1.2.3.4:8080 -p 443 bouncehost -W %h:%p ~/bin/connect.sh: #!/bin/bash if echo | nc -w 1 2.3.4.5 22 | grep -q SSH; then false else true fi So when I can't connect to the system directly it should go over a bounce host but at the same time use a portforwarding which is only available from the bouncehost but not the server itself. My problem is that -W clears all forwardings. Is there another trick or option for example with -L that allows me to forward stdin using a bounce host but let me specify additional forwardings? For now I just go back to use netcat which works fine. Cheers, Thomas