From the2nd at otpme.org Tue Dec 1 01:52:43 2015 From: the2nd at otpme.org (the2nd at otpme.org) Date: Mon, 30 Nov 2015 15:52:43 +0100 Subject: Problem with gpg-agent and yubikey since openssh v6.8p1 In-Reply-To: References: <2b0080a5d20b7f906082b534279fb197@otpme.org> Message-ID: Hi Damien, thanks for you answer. Here is the output of ssh -vvv for both versions: http://paste.ubuntu.com/13576087/ http://paste.ubuntu.com/13576243/ If you need any more info let me know. Regards the2nd On 2015-11-29 12:14, Damien Miller wrote: > On Tue, 24 Nov 2015, the2nd at otpme.org wrote: > >> Hi, >> >> i'm unsure if the problem we encounter is a bug in openssh or in >> gnupg. But as >> everything was working with openssh 6.7p1 and earlier i guess that >> there where >> at least some changes in openssh that leads to the problem. >> >> You can read the latest discussion about the problem here: >> >> https://www.mail-archive.com/gnupg-users%40gnupg.org/msg29421.html >> https://www.mail-archive.com/gnupg-users at gnupg.org/msg28416.html >> >> I hope to get some help on this list as its an very annoying problem >> and using >> an old openssh version is just a bad workaround. >> >> If you need any more information or help debugging i'm glad to help. > > At the very least, we'd need the output of "ssh -vvv user at host" for a > failing attempt. > > -d From djm at mindrot.org Tue Dec 1 09:42:20 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Dec 2015 09:42:20 +1100 (AEDT) Subject: Problem with gpg-agent and yubikey since openssh v6.8p1 In-Reply-To: References: <2b0080a5d20b7f906082b534279fb197@otpme.org> Message-ID: On Mon, 30 Nov 2015, the2nd at otpme.org wrote: > Hi Damien, > > thanks for you answer. > > Here is the output of ssh -vvv for both versions: > > http://paste.ubuntu.com/13576087/ > http://paste.ubuntu.com/13576243/ In http://paste.ubuntu.com/13576087/ the key no longer appears in the agent after the token is removed and re-inserted. If you aren't using OpenSSH's ssh-agent then you should ask whomever wrote your agent. -d From the2nd at otpme.org Tue Dec 1 10:13:20 2015 From: the2nd at otpme.org (the2nd at otpme.org) Date: Tue, 01 Dec 2015 00:13:20 +0100 Subject: Problem with gpg-agent and yubikey since openssh v6.8p1 In-Reply-To: References: <2b0080a5d20b7f906082b534279fb197@otpme.org> Message-ID: <540e00d98b1a561e3bd7477df12a1e65@otpme.org> Like written in my initial mail the agent is from gnupg. The reason why i was asking on this list is that the problem is reproducible with any openssh version newer than 6.7p1. So it seems like anything changed in openssh 6.8p1 that leads to this problem. I've also asked on the gnupg list (see the links in my first mail) and there are others that experience this issue but i got no answer from the devs yet. I'll try it again on the gnupg list if you cannot help. i just thought that there might be a chance that there where some changes in openssh between the two versions and someone on this list can help or at least can give any hint in the right direction. regards the2nd On 2015-11-30 23:42, Damien Miller wrote: > On Mon, 30 Nov 2015, the2nd at otpme.org wrote: > >> Hi Damien, >> >> thanks for you answer. >> >> Here is the output of ssh -vvv for both versions: >> >> http://paste.ubuntu.com/13576087/ >> http://paste.ubuntu.com/13576243/ > > In http://paste.ubuntu.com/13576087/ the key no longer appears in the > agent after the token is removed and re-inserted. > > If you aren't using OpenSSH's ssh-agent then you should ask whomever > wrote your agent. > > -d From mdione at grulic.org.ar Thu Dec 3 20:17:16 2015 From: mdione at grulic.org.ar (Marcos Dione) Date: Thu, 3 Dec 2015 10:17:16 +0100 Subject: public API Message-ID: <20151203091716.GO5695@diablo.grulicueva.local> Hi everybody. First of all, I'm not subscribed to the list, so please CC me in answers. Second, please don't kill me :) I'm suffering the fact that if I, as a developer, want to connect to another machine via SSH, I must use a third party library[1]. Because this is a reimplemetation of the protocol, it's always lagging behind, which only makes sense. Personally, it also looks like a waste of resources. This reimplementation comes, I think, from the fact that openssh does not provide a library with a public API as an interface for developers. So my question is: do you think it would make sense to provide such a thing directly from the openssh project? Cheers, -- Marcos. -- [1] Details here: http://www.grulic.org.ar/~mdione/glob/posts/can-I-haz-libfoo/ From zhengjunling at huawei.com Fri Dec 4 02:22:41 2015 From: zhengjunling at huawei.com (Junling Zheng) Date: Thu, 3 Dec 2015 15:22:41 +0000 Subject: [PATCH] Init kbdintctxt->devices_done Message-ID: <1449156161-16405-1-git-send-email-zhengjunling@huawei.com> Commit d73fafba6e introduced devices_done into struct KbdintAuthctxt and forgot to initialize it, which might be dangerous. Signed-off-by: Junling Zheng --- auth2-chall.c | 1 + 1 file changed, 1 insertion(+) diff --git a/auth2-chall.c b/auth2-chall.c index 4aff09d..14d14af 100644 --- a/auth2-chall.c +++ b/auth2-chall.c @@ -132,6 +132,7 @@ kbdint_alloc(const char *devs) kbdintctxt->ctxt = NULL; kbdintctxt->device = NULL; kbdintctxt->nreq = 0; + kbdintctxt->devices_done = 0; return kbdintctxt; } -- 1.8.3.4 From djm at mindrot.org Fri Dec 4 08:39:36 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 4 Dec 2015 08:39:36 +1100 (AEDT) Subject: public API In-Reply-To: <20151203091716.GO5695@diablo.grulicueva.local> References: <20151203091716.GO5695@diablo.grulicueva.local> Message-ID: On Thu, 3 Dec 2015, Marcos Dione wrote: > > Hi everybody. First of all, I'm not subscribed to the list, so please > CC me in answers. > > Second, please don't kill me :) > > I'm suffering the fact that if I, as a developer, want to connect to > another machine via SSH, I must use a third party library[1]. Because > this is a reimplemetation of the protocol, it's always lagging behind, > which only makes sense. Personally, it also looks like a waste of > resources. > > This reimplementation comes, I think, from the fact that openssh does > not provide a library with a public API as an interface for developers. > So my question is: do you think it would make sense to provide such a > thing directly from the openssh project? We're slowly moving towards making parts of OpenSSH available as a library, but progress has been slow and we've mostly been focusing on cleanups and improving testability. In the meantime, I suggest you check out https://www.libssh.org/ -D From security.veteran at gmail.com Fri Dec 4 13:26:05 2015 From: security.veteran at gmail.com (security veteran) Date: Thu, 3 Dec 2015 18:26:05 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? Message-ID: Hi All: I tried to rebuild openssl with the FIPS modules, and then install the new openssl libs (lib crypto.so to be specific) on my Ubuntu 12.04 box. After that I noticed it seemed to break OpenSSH: I couldn't login to the box using ssh, and couldn't run the client command like ssh-keygen either. My questions are: 1. Does OpenSSH support FIPS mode? 2. Or does OpenSSH support with OpenSSL FIPS modules? 3. Is there a way to re-compile OpenSSH by turning on/off some flags to make it FIPS complaint? 4. Does the RedHat OpenSSH FIPS modules ( http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) also open sourced to the OpenSSH community? Thanks. From tomas.kuthan at oracle.com Fri Dec 4 19:39:47 2015 From: tomas.kuthan at oracle.com (Tomas Kuthan) Date: Fri, 04 Dec 2015 09:39:47 +0100 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: Message-ID: <56615153.2040705@oracle.com> On 12/ 4/15 03:26 AM, security veteran wrote: > Hi All: > > I tried to rebuild openssl with the FIPS modules, and then install the new > openssl libs (lib crypto.so to be specific) on my Ubuntu 12.04 box. > > After that I noticed it seemed to break OpenSSH: I couldn't login to the > box using ssh, and couldn't run the client command like ssh-keygen either. > > My questions are: > > 1. Does OpenSSH support FIPS mode? > > 2. Or does OpenSSH support with OpenSSL FIPS modules? > > 3. Is there a way to re-compile OpenSSH by turning on/off some flags to > make it FIPS complaint? > > 4. Does the RedHat OpenSSH FIPS modules ( > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) > also open sourced to the OpenSSH community? Hi security veteran, vanilla OpenSSH doesn't support running OpenSSL in FIPS-140 mode. Some downstream providers patch OpenSSH they deliver with their distributions with changes to enable FIPS-140 mode. In general, an application that wants to run a FIPS-140 capable OpenSSL library in FIPS-140 mode, needs to call FIPS_mode_set() first. Otherwise it runs OpenSSL in default mode with non-FIPS algorithms available. From my experience this works, but is not FIPS-140 compliant. User Guide for the OpenSSL FIPS Object Module v2.0 [1]: > 2.6 > FIPS Mode of Operation > Applications that utilize FIPS mode must call the FIPS_mode_set() function. After successful > FIPS mode initialization, the non-FIPS algorithms will be disabled by default. > The FIPS Object Module together with a compatible version of the OpenSSL product can be used > in the generation of both FIPS mode and conventional applications. In this sense, the combination > of the FIPS Object Module and the usual OpenSSL libraries constitutes a ?FIPS capable API?, and > provide both FIP approved algorithms and non-FIPS algorithms. Vanilla OpenSSH obviously doesn't call FIPS_mode_set(). If switching underlying OpenSSL libcrypto to FIPS-140 capable instance precludes you from running ssh, most probably there is something wrong with the FIPS-140 capable OpenSSL you built. Tomas [1] https://openssl.org/docs/fips/UserGuide-2.0.pdf From sfandino at gmail.com Fri Dec 4 20:31:49 2015 From: sfandino at gmail.com (=?UTF-8?Q?Salvador_Fandi=c3=b1o?=) Date: Fri, 4 Dec 2015 10:31:49 +0100 Subject: public API In-Reply-To: References: <20151203091716.GO5695@diablo.grulicueva.local> Message-ID: <56615D85.1070802@gmail.com> On 12/03/2015 10:39 PM, Damien Miller wrote: > On Thu, 3 Dec 2015, Marcos Dione wrote: > >> >> Hi everybody. First of all, I'm not subscribed to the list, so please >> CC me in answers. >> >> Second, please don't kill me :) >> >> I'm suffering the fact that if I, as a developer, want to connect to >> another machine via SSH, I must use a third party library[1]. Because >> this is a reimplemetation of the protocol, it's always lagging behind, >> which only makes sense. Personally, it also looks like a waste of >> resources. >> >> This reimplementation comes, I think, from the fact that openssh does >> not provide a library with a public API as an interface for developers. >> So my question is: do you think it would make sense to provide such a >> thing directly from the openssh project? > > We're slowly moving towards making parts of OpenSSH available as a library, > but progress has been slow and we've mostly been focusing on cleanups and > improving testability. > > In the meantime, I suggest you check out https://www.libssh.org/ Marcos, You can also use OpenSSH client as a slave process. I have been able to come quite far doing that on my Perl module Net::OpenSSH (https://metacpan.org/pod/Net::OpenSSH) (ab)using the connection multiplexing feature. There are some rough edges when doing that, especially on the hand-shake stages of SSH, as "ssh" is completely opaque then and for instance it is impossible to retrieve the specific error when some connection fails. But on the other hand, presenting the SSH channels as regular file descriptors in the API, instead of some custom abstraction, has allowed me to integrate external tools such as rsync or sshfs and other Perl modules as Expect or Net::Telnet quite easily. I am also currently the de-facto maintainer for Net::SSH2, the Perl wrapper for libssh2. I have tried to replicate the high level API of Net::OpenSSH on top of Net::SSH2 (in Net::SSH::Any) and it has been quite challenging. There are even several things that I have just not been able to do in a reasonable simple and reliable way (i.e. running an external command over a channel). From jjelen at redhat.com Fri Dec 4 23:26:36 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Fri, 4 Dec 2015 13:26:36 +0100 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: Message-ID: <5661867C.7000001@redhat.com> On 12/04/2015 03:26 AM, security veteran wrote: > 3. Is there a way to re-compile OpenSSH by turning on/off some flags to > make it FIPS complaint? > > 4. Does the RedHat OpenSSH FIPS modules ( > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) > also open sourced to the OpenSSH community? Yes, what we ship in RHEL is open-source. You can pick up sources that are actually used in RHEL version in CentOS repository: https://git.centos.org/summary/?r=rpms/openssh So as said before, upstream openssh is not FIPS-140 ready and we carry the patches downstream. I am not sure if there was initiative to provide patches upstream or if there would be some interest in them here, since it is quite special use case. -- Jakub Jelen Security Technologies Red Hat From security.veteran at gmail.com Sat Dec 5 02:38:22 2015 From: security.veteran at gmail.com (security veteran) Date: Fri, 4 Dec 2015 07:38:22 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: <56615153.2040705@oracle.com> References: <56615153.2040705@oracle.com> Message-ID: Hi Tomas, Thanks for your answers! So based on your answers: 1. Since Vanilla OpenSSH doesn't call FIPS_mode_set() function, it should work just fine even if the OpenSSL libcrypto.so library has already been changed to the FIPS version. Is that correct? 2. Looks like there is no such a flag in OpenSSH source to allow you rebuild it and turn it into FIPS compliant mode, is that correct? In that case is there a way to re-build OpenSSH server and client (somehow in both the RedHat and Ubuntu, the OpenSSH is split into two (openssh-server and openssl-client) packages, so that the non-FIPS compliant functions can be disabled? Thanks. On Fri, Dec 4, 2015 at 12:39 AM, Tomas Kuthan wrote: > On 12/ 4/15 03:26 AM, security veteran wrote: > >> Hi All: >> >> I tried to rebuild openssl with the FIPS modules, and then install the new >> openssl libs (lib crypto.so to be specific) on my Ubuntu 12.04 box. >> >> After that I noticed it seemed to break OpenSSH: I couldn't login to the >> box using ssh, and couldn't run the client command like ssh-keygen either. >> >> My questions are: >> >> 1. Does OpenSSH support FIPS mode? >> >> 2. Or does OpenSSH support with OpenSSL FIPS modules? >> >> 3. Is there a way to re-compile OpenSSH by turning on/off some flags to >> make it FIPS complaint? >> >> 4. Does the RedHat OpenSSH FIPS modules ( >> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) >> also open sourced to the OpenSSH community? >> > > Hi security veteran, > > vanilla OpenSSH doesn't support running OpenSSL in FIPS-140 mode. Some > downstream providers patch OpenSSH they deliver with their distributions > with changes to enable FIPS-140 mode. > > In general, an application that wants to run a FIPS-140 capable OpenSSL > library in FIPS-140 mode, needs to call FIPS_mode_set() first. Otherwise it > runs OpenSSL in default mode with non-FIPS algorithms available. From my > experience this works, but is not FIPS-140 compliant. > > User Guide for the OpenSSL FIPS Object Module v2.0 [1]: > >> 2.6 >> FIPS Mode of Operation >> Applications that utilize FIPS mode must call the FIPS_mode_set() >> function. After successful >> FIPS mode initialization, the non-FIPS algorithms will be disabled by >> default. >> The FIPS Object Module together with a compatible version of the OpenSSL >> product can be used >> in the generation of both FIPS mode and conventional applications. In >> this sense, the combination >> of the FIPS Object Module and the usual OpenSSL libraries constitutes a >> ?FIPS capable API?, and >> provide both FIP approved algorithms and non-FIPS algorithms. >> > > Vanilla OpenSSH obviously doesn't call FIPS_mode_set(). If switching > underlying OpenSSL libcrypto to FIPS-140 capable instance precludes you > from running ssh, most probably there is something wrong with the FIPS-140 > capable OpenSSL you built. > > Tomas > > [1] https://openssl.org/docs/fips/UserGuide-2.0.pdf > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From Kam.Nasim at windriver.com Sat Dec 5 03:23:10 2015 From: Kam.Nasim at windriver.com (Nasim, Kam) Date: Fri, 4 Dec 2015 16:23:10 +0000 Subject: Running sshd with Privilege Seperation drops connection on password change Message-ID: Hi folks, I came across this issue on both stock CentOS(v6.4) and Ubuntu(14.04 LTS) and was wondering if any of you have seen it. As far as I can tell this seems like a day-1 bug to me. PROBLEM: If I expire a linux user's password (passwd -e ) and then log in via ssh, it will prompt you for a password change. On changing the password successfully, sshd will drop the connection and client has to reconnect. ANALYSIS: Looking at sshd debug logs, it would appear that the child process that runs passwd SIGCHLD's to the parent which appears to be treating that signal as a SIGTERM: Dec 3 18:36:17 knasim-ubuntu1 passwd[3152]: pam_unix(passwd:chauthtok): password changed for wrs <<<<<<< Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: Received SIGCHLD. <<<<<<<<<<<<<<<<<< Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_by_pid: pid 3152 Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_exit_message: session 0 channel 0 pid 3152 Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug2: channel 0: request exit-status confirm 0 <<<<<<<<<<< By default, in sshd "Privilege Separation" is enabled. What does this mean? It means that sshd spawns an unprivileged process that does basic authentication and that guy spawns a child process running as root to run passwd (in this case). After password change, the child SIGCHLD's the parent which instead of handling it properly treats it like a SIGTERM and closes the socket. The following process tree should give a better idea of the process nestings: With Privilege Separation: ubuntu at knasim-ubuntu1:~$ pstree init???acpid ??atd ??cron ??dbus-daemon ??dhclient ??7*[getty] ??rsyslogd???3*[{rsyslogd}] ??sshd???bash???ssh ??sshd???bash???pstree ??sshd???sshd???sshd???passwd ??systemd-logind ??systemd-udevd ??upstart-file-br ??upstart-socket- ??upstart-udev-br Without Privilege Separation: init???acpid ??atd ??cron ??dbus-daemon ??dhclient ??7*[getty] ??rsyslogd???3*[{rsyslogd}] ??sshd???sshd???bash???ssh ? ??sshd???bash???pstree ? ??sshd???sshd ??systemd-logind ??systemd-udevd ??upstart-file-br ??upstart-socket- ??upstart-udev-br If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication. What do you guys think? Have others come across this? Is there a patch available for this? Thanks, Kam From security.veteran at gmail.com Sat Dec 5 07:58:18 2015 From: security.veteran at gmail.com (security veteran) Date: Fri, 4 Dec 2015 12:58:18 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: <5661867C.7000001@redhat.com> References: <5661867C.7000001@redhat.com> Message-ID: Thanks Jakub. How does this patch match the OpenSSH source version? Does the patch only applicable to OpenSSH version 6.6.1, or does other version available as well? Thanks. On Fri, Dec 4, 2015 at 4:26 AM, Jakub Jelen wrote: > > On 12/04/2015 03:26 AM, security veteran wrote: > >> 3. Is there a way to re-compile OpenSSH by turning on/off some flags to >> make it FIPS complaint? >> >> 4. Does the RedHat OpenSSH FIPS modules ( >> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) >> also open sourced to the OpenSSH community? >> > Yes, what we ship in RHEL is open-source. You can pick up sources that are > actually used in RHEL version in CentOS repository: > https://git.centos.org/summary/?r=rpms/openssh > > So as said before, upstream openssh is not FIPS-140 ready and we carry the > patches downstream. I am not sure if there was initiative to provide > patches upstream or if there would be some interest in them here, since it > is quite special use case. > > -- > Jakub Jelen > Security Technologies > Red Hat > > From security.veteran at gmail.com Sat Dec 5 08:02:17 2015 From: security.veteran at gmail.com (security veteran) Date: Fri, 4 Dec 2015 13:02:17 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: <5661867C.7000001@redhat.com> Message-ID: Hi Jakub, Another question I have is, are there any changes in this patch RedHat Linux distribution specific? The reason I ask is, if I port the changes to other Linux distribution like Debian or Ubuntu, do you see any issues? Thanks. On Fri, Dec 4, 2015 at 12:58 PM, security veteran < security.veteran at gmail.com> wrote: > Thanks Jakub. > > How does this patch match the OpenSSH source version? Does the patch only > applicable to OpenSSH version 6.6.1, or does other version available as > well? > > Thanks. > > > On Fri, Dec 4, 2015 at 4:26 AM, Jakub Jelen wrote: > >> >> On 12/04/2015 03:26 AM, security veteran wrote: >> >>> 3. Is there a way to re-compile OpenSSH by turning on/off some flags to >>> make it FIPS complaint? >>> >>> 4. Does the RedHat OpenSSH FIPS modules ( >>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf >>> ) >>> also open sourced to the OpenSSH community? >>> >> Yes, what we ship in RHEL is open-source. You can pick up sources that >> are actually used in RHEL version in CentOS repository: >> https://git.centos.org/summary/?r=rpms/openssh >> >> So as said before, upstream openssh is not FIPS-140 ready and we carry >> the patches downstream. I am not sure if there was initiative to provide >> patches upstream or if there would be some interest in them here, since it >> is quite special use case. >> >> -- >> Jakub Jelen >> Security Technologies >> Red Hat >> >> > From rausalinas at gmail.com Sun Dec 6 08:54:53 2015 From: rausalinas at gmail.com (=?UTF-8?Q?Ra=C3=BAl_Salinas_Monteagudo?=) Date: Sat, 5 Dec 2015 22:54:53 +0100 Subject: ssh client: chdir("/") Message-ID: Dear ssh developers, I seem to have experienced sometimes the case where an ssh client was preventing me from unmounting a partition. Then I have checked that ssh processes do not alter their working directory indeed, not even if executed with "-f". Do you believe it makes sense to chdir("/") just before entering the main loop (after reading files that were possibly specified with a relative name)? Is the current directory at the client side used for anything else? Maybe before "exit_status = compat20 ? ssh_session2() : ssh_session();". Thanks, Ra?l Salinas From openssh at roumenpetrov.info Sun Dec 6 20:30:50 2015 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 06 Dec 2015 11:30:50 +0200 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: Message-ID: <5664004A.3080009@roumenpetrov.info> security veteran wrote: > Hi All: > > I tried to rebuild openssl with the FIPS modules, and then install the new > openssl libs (lib crypto.so to be specific) on my Ubuntu 12.04 box. > > After that I noticed it seemed to break OpenSSH: I couldn't login to the > box using ssh, and couldn't run the client command like ssh-keygen either. > > My questions are: > > 1. Does OpenSSH support FIPS mode? > > 2. Or does OpenSSH support with OpenSSL FIPS modules? > > 3. Is there a way to re-compile OpenSSH by turning on/off some flags to > make it FIPS complaint? > > 4. Does the RedHat OpenSSH FIPS modules ( > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) > also open sourced to the OpenSSH community? > Redhat use different FIPS validation process for OpenSSL. You could extract fips patch from source package. Impact is not only for source code. Build process has to be updated as well. Red Hat is based on "fipscheck". You could try with my version of secure shell. It include OpenSSH but adds support for public keys algorithms based on X.509 certificates support and works with FIPS enabled openssl. It should work with OpenSSL build with FIPS module , RedHat or Solaris openssl fips enabled library either in fips mode or not. Regards, Roumen Petrov -- Get SSH with X.509 certificate support http://roumenpetrov.info/openssh/ From djm at mindrot.org Mon Dec 7 15:15:55 2015 From: djm at mindrot.org (Damien Miller) Date: Mon, 7 Dec 2015 15:15:55 +1100 (AEDT) Subject: Running sshd with Privilege Seperation drops connection on password change In-Reply-To: References: Message-ID: Hi, We'll need to see a full debug log from the server - it's not possible to see what is going one from the abridged ones you sent. -d On Fri, 4 Dec 2015, Nasim, Kam wrote: > Hi folks, > > I came across this issue on both stock CentOS(v6.4) and Ubuntu(14.04 LTS) and was wondering if any of you have seen it. > As far as I can tell this seems like a day-1 bug to me. > > PROBLEM: > If I expire a linux user's password (passwd -e ) and then log in via ssh, it will prompt you for a password change. > On changing the password successfully, sshd will drop the connection and client has to reconnect. > > > ANALYSIS: > > Looking at sshd debug logs, it would appear that the child process that runs passwd SIGCHLD's to the parent which appears to be treating that signal as a SIGTERM: > > Dec 3 18:36:17 knasim-ubuntu1 passwd[3152]: pam_unix(passwd:chauthtok): password changed for wrs <<<<<<< > Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: Received SIGCHLD. <<<<<<<<<<<<<<<<<< > Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_by_pid: pid 3152 > Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_exit_message: session 0 channel 0 pid 3152 > Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug2: channel 0: request exit-status confirm 0 <<<<<<<<<<< > > > By default, in sshd "Privilege Separation" is enabled. What does this mean? > > It means that sshd spawns an unprivileged process that does basic authentication and that guy spawns a child process running as root to run passwd (in this case). > > After password change, the child SIGCHLD's the parent which instead of handling it properly treats it like a SIGTERM and closes the socket. > > The following process tree should give a better idea of the process nestings: > > With Privilege Separation: > ubuntu at knasim-ubuntu1:~$ pstree > init???acpid > ??atd > ??cron > ??dbus-daemon > ??dhclient > ??7*[getty] > ??rsyslogd???3*[{rsyslogd}] > ??sshd???bash???ssh > ??sshd???bash???pstree > ??sshd???sshd???sshd???passwd > ??systemd-logind > ??systemd-udevd > ??upstart-file-br > ??upstart-socket- > ??upstart-udev-br > > Without Privilege Separation: > init???acpid > ??atd > ??cron > ??dbus-daemon > ??dhclient > ??7*[getty] > ??rsyslogd???3*[{rsyslogd}] > ??sshd???sshd???bash???ssh > ? ??sshd???bash???pstree > ? ??sshd???sshd > ??systemd-logind > ??systemd-udevd > ??upstart-file-br > ??upstart-socket- > ??upstart-udev-br > > If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication. > > > What do you guys think? Have others come across this? Is there a patch available for this? > > Thanks, > Kam > _______________________________________________ > 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 Mon Dec 7 15:47:48 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 7 Dec 2015 15:47:48 +1100 Subject: Running sshd with Privilege Seperation drops connection on password change In-Reply-To: References: Message-ID: There's 3 ways that sshd will force you to change an expired password when you have PAM enabled (which you do): 1) if you're using keyboard-interactive authentication, sshd will call pam_chauthtok() as part of the authentication. This should work with or without privsep. If you authenticate some other way (eg password), sshd will force you to change your password once you start your session. 2) if you have privilege separation enabled, by the time your session starts sshd has dropped the privileges needed to successfully call pam_chauthtok(). Instead, it'll exec /bin/passwd. 3) if you have privsep disabled, sshd is still running as root and will call pam_chauthtok(). On Sat, Dec 5, 2015 at 3:23 AM, Nasim, Kam wrote: [...] > PROBLEM: > If I expire a linux user's password (passwd -e ) and then log in via ssh, it will prompt you for a password change. > On changing the password successfully, sshd will drop the connection and client has to reconnect. That's working as intended, and you should have seen text to that effect. In session.c (simplified): static void do_pwchange(Session *s) { fprintf(stderr, "WARNING: Your password has expired.\n"); if (s->ttyfd != -1) { fprintf(stderr, "You must change your password now and login again!\n"); execl(_PATH_PASSWD_PROG, "passwd", (char *)NULL); > If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication. RIght, see #3 above. -- 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 security.veteran at gmail.com Tue Dec 8 02:44:44 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 7 Dec 2015 07:44:44 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: <5664004A.3080009@roumenpetrov.info> References: <5664004A.3080009@roumenpetrov.info> Message-ID: Thanks Roumen. I have few more questions below: 1. What version of OpenSSH can the patch be applied to? What branch should I check out the patch? 2. >Impact is not only for source code. Build process has to be updated as well. Red Hat is based on "fipscheck". What build process should be changed? What is fipscheck? 3. My understanding any application (such as OpenSSH) which need to use the OpenSSL FIPS module will need to invoke the "FIPS_mode_set()" function first, otherwise the OpenSSL library will be operating as the non-FIPS version. My question is, how and when does OpenSSH server invoke the FIPS function? Thanks. On Sun, Dec 6, 2015 at 1:30 AM, Roumen Petrov wrote: > security veteran wrote: > >> Hi All: >> >> I tried to rebuild openssl with the FIPS modules, and then install the new >> openssl libs (lib crypto.so to be specific) on my Ubuntu 12.04 box. >> >> After that I noticed it seemed to break OpenSSH: I couldn't login to the >> box using ssh, and couldn't run the client command like ssh-keygen either. >> >> My questions are: >> >> 1. Does OpenSSH support FIPS mode? >> >> 2. Or does OpenSSH support with OpenSSL FIPS modules? >> >> 3. Is there a way to re-compile OpenSSH by turning on/off some flags to >> make it FIPS complaint? >> >> 4. Does the RedHat OpenSSH FIPS modules ( >> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1791.pdf) >> also open sourced to the OpenSSH community? >> >> Redhat use different FIPS validation process for OpenSSL. You could > extract fips patch from source package. > Impact is not only for source code. Build process has to be updated as > well. Red Hat is based on "fipscheck". > > You could try with my version of secure shell. It include OpenSSH but adds > support for public keys algorithms based on X.509 certificates support and > works with FIPS enabled openssl. > It should work with OpenSSL build with FIPS module , RedHat or Solaris > openssl fips enabled library either in fips mode or not. > > Regards, > Roumen Petrov > > -- > Get SSH with X.509 certificate support > http://roumenpetrov.info/openssh/ > > From jjelen at redhat.com Tue Dec 8 02:53:47 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 7 Dec 2015 16:53:47 +0100 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: <5661867C.7000001@redhat.com> Message-ID: <5665AB8B.7030803@redhat.com> On 12/04/2015 10:02 PM, security veteran wrote: > Hi Jakub, > > Another question I have is, are there any changes in this patch RedHat > Linux distribution specific? The reason I ask is, if I port the changes to > other Linux distribution like Debian or Ubuntu, do you see any issues? I don't think there is something distro-specific. Distro specific parts are handled in other patches. > Thanks. > > On Fri, Dec 4, 2015 at 12:58 PM, security veteran < > security.veteran at gmail.com> wrote: > >> Thanks Jakub. >> >> How does this patch match the OpenSSH source version? Does the patch only >> applicable to OpenSSH version 6.6.1, or does other version available as >> well? >> >> Thanks. We were doing certification for openssh-6.6.1 last time, since it is the thing we ship in our recent system. But we are maintaining similar patch for current openssh version (though the name is outdated, it is for 7.1p1) for Fedora [1], even though it is not "verified" by certification, it should fulfill similar requirements. [1] http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch -- Jakub Jelen Security Technologies Red Hat From openssh at roumenpetrov.info Tue Dec 8 06:39:42 2015 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Mon, 07 Dec 2015 21:39:42 +0200 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: <5664004A.3080009@roumenpetrov.info> Message-ID: <5665E07E.7030005@roumenpetrov.info> security veteran wrote: > Thanks Roumen. > > I have few more questions below: > > 1. What version of OpenSSH can the patch be applied to? What branch should > I check out the patch? There is no separate patch but I offer file with all differences to openssh - see link (diff) on download page http://roumenpetrov.info/openssh/download.html > 2. >> Impact is not only for source code. Build process has to be updated as > well. Red Hat is based on "fipscheck". > What build process should be changed? What is fipscheck? I different way to check integrity of files(executables) - https://fedorahosted.org / fipscheck/ . > 3. My understanding any application (such as OpenSSH) which need to use the > OpenSSL FIPS module will need to invoke the "FIPS_mode_set()" function > first, otherwise the OpenSSL library will be operating as the non-FIPS > version. > My question is, how and when does OpenSSH server invoke the FIPS function? Lets assume that application use OpenSSL FIPS validated module. FIPS mode is activated in openssl command if environment variable OPENSSL_FIPS is set. Similarly I use OPENSSL_FIPS environment variable to activate FIPS mode. Code will call FIPS_mode_set(1) if crypto module is not FIPS mode. [SNIP] Roumen From security.veteran at gmail.com Tue Dec 8 07:15:33 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 7 Dec 2015 12:15:33 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: <5665E07E.7030005@roumenpetrov.info> References: <5664004A.3080009@roumenpetrov.info> <5665E07E.7030005@roumenpetrov.info> Message-ID: Thanks Roumen. >Lets assume that application use OpenSSL FIPS validated module. FIPS mode is activated in openssl command if environment variable OPENSSL_FIPS is set. Similarly I use OPENSSL_FIPS environment variable to activate FIPS mode. Code will call FIPS_mode_set(1) if crypto module is not FIPS mode. Did you mean the FIPS patched OpenSSH server and client (such as ssh-keygen) always check the environmental variable OPENSSL_FIPS to see if the FIPS mode is activated? Also I think for the applications which need to use OpenSSL FIPS mode will also need to run the FIPS self tests functions (also provided by the OpenSSL FIPS modules). Does the patched OpenSSH also run these self tests? Thanks. On Mon, Dec 7, 2015 at 11:39 AM, Roumen Petrov wrote: > security veteran wrote: > >> Thanks Roumen. >> >> I have few more questions below: >> >> 1. What version of OpenSSH can the patch be applied to? What branch should >> I check out the patch? >> > There is no separate patch but I offer file with all differences to > openssh - see link (diff) on download page > http://roumenpetrov.info/openssh/download.html > > 2. >> >>> Impact is not only for source code. Build process has to be updated as >>> >> well. Red Hat is based on "fipscheck". >> What build process should be changed? What is fipscheck? >> > I different way to check integrity of files(executables) - > https://fedorahosted.org / fipscheck/ . > > 3. My understanding any application (such as OpenSSH) which need to use the >> OpenSSL FIPS module will need to invoke the "FIPS_mode_set()" function >> first, otherwise the OpenSSL library will be operating as the non-FIPS >> version. >> My question is, how and when does OpenSSH server invoke the FIPS function? >> > Lets assume that application use OpenSSL FIPS validated module. FIPS mode > is activated in openssl command if environment variable OPENSSL_FIPS is > set. Similarly I use OPENSSL_FIPS environment variable to activate FIPS > mode. Code will call FIPS_mode_set(1) if crypto module is not FIPS mode. > > > [SNIP] > > Roumen > From security.veteran at gmail.com Tue Dec 8 07:21:29 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 7 Dec 2015 12:21:29 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: <5665AB8B.7030803@redhat.com> References: <5661867C.7000001@redhat.com> <5665AB8B.7030803@redhat.com> Message-ID: Thanks Jakub. If I want to build the FIPS supported OpenSSH, do I just need to apply this one single patch http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch to the vanilla OpenSSH source code? I saw there are few other patches for OpenSSH version 6.7p1 under the same folder http://pkgs.fedoraproject.org/cgit/openssh.git/tree/. Do I need these other patches? Thanks. On Mon, Dec 7, 2015 at 7:53 AM, Jakub Jelen wrote: > On 12/04/2015 10:02 PM, security veteran wrote: > >> Hi Jakub, >> >> Another question I have is, are there any changes in this patch RedHat >> Linux distribution specific? The reason I ask is, if I port the changes to >> other Linux distribution like Debian or Ubuntu, do you see any issues? >> > I don't think there is something distro-specific. Distro specific parts > are handled in other patches. > > Thanks. >> >> On Fri, Dec 4, 2015 at 12:58 PM, security veteran < >> security.veteran at gmail.com> wrote: >> >> Thanks Jakub. >>> >>> How does this patch match the OpenSSH source version? Does the patch only >>> applicable to OpenSSH version 6.6.1, or does other version available as >>> well? >>> >>> Thanks. >>> >> > We were doing certification for openssh-6.6.1 last time, since it is the > thing we ship in our recent system. But we are maintaining similar patch > for current openssh version (though the name is outdated, it is for 7.1p1) > for Fedora [1], even though it is not "verified" by certification, it > should fulfill similar requirements. > > [1] > http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch > > > -- > Jakub Jelen > Security Technologies > Red Hat > > From openssh at roumenpetrov.info Tue Dec 8 07:52:32 2015 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Mon, 07 Dec 2015 22:52:32 +0200 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: <5664004A.3080009@roumenpetrov.info> <5665E07E.7030005@roumenpetrov.info> Message-ID: <5665F190.3010404@roumenpetrov.info> security veteran wrote: > Thanks Roumen. > >> Lets assume that application use OpenSSL FIPS validated module. FIPS mode > is activated in openssl command if environment variable OPENSSL_FIPS is > set. Similarly I use OPENSSL_FIPS environment variable to activate FIPS > mode. Code will call FIPS_mode_set(1) if crypto module is not FIPS mode. > > Did you mean the FIPS patched OpenSSH server and client (such as > ssh-keygen) always check the environmental variable OPENSSL_FIPS to see if > the FIPS mode is activated? > Also I think for the applications which need to use OpenSSL FIPS mode will > also need to run the FIPS self tests functions (also provided by the > OpenSSL FIPS modules). Does the patched OpenSSH also run these self tests? Openssl os open source. The method FIPS_mode_set will call FIPS_module_mode_set (located in FIPS module) . Please see its code. You may review code of apps/openssl.c. [SNIP] Roumen From security.veteran at gmail.com Tue Dec 8 08:11:08 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 7 Dec 2015 13:11:08 -0800 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: <5665F190.3010404@roumenpetrov.info> References: <5664004A.3080009@roumenpetrov.info> <5665E07E.7030005@roumenpetrov.info> <5665F190.3010404@roumenpetrov.info> Message-ID: Thanks Roumen. >Openssl os open source. The method FIPS_mode_set will call FIPS_module_mode_set (located in FIPS module) . Please see its code. You may review code of apps/openssl.c. I meant, did your OpenSSH patch actually invoke these functions (FIPS_mode_set and FIPS_selftest)? If that's the case, when were these functions invoked? e.g. for client application such as ssh-keygen does it always call these functions first? Thanks. On Mon, Dec 7, 2015 at 12:52 PM, Roumen Petrov wrote: > security veteran wrote: > >> Thanks Roumen. >> >> Lets assume that application use OpenSSL FIPS validated module. FIPS mode >>> >> is activated in openssl command if environment variable OPENSSL_FIPS is >> set. Similarly I use OPENSSL_FIPS environment variable to activate FIPS >> mode. Code will call FIPS_mode_set(1) if crypto module is not FIPS mode. >> >> Did you mean the FIPS patched OpenSSH server and client (such as >> ssh-keygen) always check the environmental variable OPENSSL_FIPS to see if >> the FIPS mode is activated? >> Also I think for the applications which need to use OpenSSL FIPS mode will >> also need to run the FIPS self tests functions (also provided by the >> OpenSSL FIPS modules). Does the patched OpenSSH also run these self tests? >> > Openssl os open source. The method FIPS_mode_set will call > FIPS_module_mode_set (located in FIPS module) . Please see its code. > You may review code of apps/openssl.c. > > [SNIP] > > Roumen > > From openssh at roumenpetrov.info Tue Dec 8 08:17:40 2015 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Mon, 07 Dec 2015 23:17:40 +0200 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: <5664004A.3080009@roumenpetrov.info> <5665E07E.7030005@roumenpetrov.info> <5665F190.3010404@roumenpetrov.info> Message-ID: <5665F774.3030603@roumenpetrov.info> security veteran wrote: > Thanks Roumen. > >> Openssl os open source. The method FIPS_mode_set will call > FIPS_module_mode_set (located in FIPS module) . Please see its code. > You may review code of apps/openssl.c. > > I meant, did your OpenSSH patch actually invoke these functions (FIPS_mode_set > and FIPS_selftest)? If that's the case, when were these functions invoked? > e.g. for client application such as ssh-keygen does it always call these > functions first? Yes - see code of method ssh_OpenSSL_startup . $ grep -lw ssh_OpenSSL_startup *.c ssh-add.c ssh-agent.c ssh.c sshd.c ssh-keygen.c ssh-keysign.c Roumen From jjelen at redhat.com Wed Dec 9 00:27:52 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 8 Dec 2015 14:27:52 +0100 Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? In-Reply-To: References: <5661867C.7000001@redhat.com> <5665AB8B.7030803@redhat.com> Message-ID: <5666DAD8.3040203@redhat.com> On 12/07/2015 09:21 PM, security veteran wrote: > Thanks Jakub. > > If I want to build the FIPS supported OpenSSH, do I just need to apply this > one single patch > http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch > > to the vanilla OpenSSH source code? > > I saw there are few other patches for OpenSSH version 6.7p1 under the same > folder http://pkgs.fedoraproject.org/cgit/openssh.git/tree/. > Do I need these other patches? It should be enough to add that one, directly related to FIPS. There were other unused patches, which I cleaned up now. -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From andrei650816 at gmail.com Wed Dec 9 19:43:23 2015 From: andrei650816 at gmail.com (Andrey Klimentev) Date: Wed, 9 Dec 2015 11:43:23 +0300 Subject: Fwd: sshd "getpeername failed: Transport endpoint is not connected" error In-Reply-To: References: Message-ID: Hello, everybody. I've recently encountered a problem with OpenSSH server. Could you help me to troubleshoot it? I've configured 2 IP interfaces[1]: one with a public IP adress and one with a private address. When I connect[2] through the public interface (ens34), SSH works fine, but when I connect[3] through the private interface (ens32), I receive a rather cryptic message on my client - "ssh_exchange_identification: read: Connection reset by peer". And this on my server - getpeername failed: Transport endpoint is not connected". I am using OpenSSH_7.1p1, OpenSSL 1.0.2e 3 Dec 2015. It is the latest version available in Arch Linux repo. -- [1] http://pastebin.com/8BF0N84t - interface conf and routing table [2] http://pastebin.com/QptpeF7f - remote log and strace [3] http://pastebin.com/niFJac46 - local log and strace From george.shuklin at gmail.com Thu Dec 10 06:04:11 2015 From: george.shuklin at gmail.com (George Shuklin) Date: Wed, 9 Dec 2015 21:04:11 +0200 Subject: [feature request] Reverse socks proxy Message-ID: <56687B2B.4070205@gmail.com> Hello. OpenSSH has -D option to create socks proxy (take local traffic and send it from remote machine). But sometimes there is an opposite problem: to allow apps on remote machine send traffic from local machine (for example, to get access to intranet resources). Expected syntax (I use -B as fist unused letter, plus it may be memorized as 'back'): ssh -B 127.0.0.1:1080 user at remote_server Creates a socks proxy for remote machine, all requests on remove machine coming to 127.0.0.1:1080 are served by local ssh client. Right now it can be implemented as combination of ssh -D 1080 localhost &; ssh -R 127.1:1080:127.1:1080 user at remote, but it is very inelegant. Thanks! From dtucker at zip.com.au Thu Dec 10 09:50:22 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Dec 2015 09:50:22 +1100 Subject: [feature request] Reverse socks proxy In-Reply-To: <56687B2B.4070205@gmail.com> References: <56687B2B.4070205@gmail.com> Message-ID: On Thu, Dec 10, 2015 at 6:04 AM, George Shuklin wrote: > Hello. > > OpenSSH has -D option to create socks proxy (take local traffic and send it > from remote machine). But sometimes there is an opposite problem: to allow > apps on remote machine send traffic from local machine (for example, to get > access to intranet resources). There is an existing enhancement request for this with attached patch (I have not looked at it in any detail or tried it though). https://bugzilla.mindrot.org/show_bug.cgi?id=2393 -- 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 Fri Dec 11 13:47:28 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Dec 2015 13:47:28 +1100 Subject: sshd "getpeername failed: Transport endpoint is not connected" error In-Reply-To: References: Message-ID: On Wed, Dec 9, 2015 at 7:43 PM, Andrey Klimentev wrote: > Hello, everybody. > > I've recently encountered a problem with OpenSSH server. Could you > help me to troubleshoot it? > > I've configured 2 IP interfaces[1]: one with a public IP adress and > one with a private address. When I connect[2] through the public > interface (ens34), SSH works fine, but when I connect[3] through the > private interface (ens32), I receive a rather cryptic message on my > client - "ssh_exchange_identification: read: Connection reset by > peer". "reset by peer" usually means the TCP connection has been torn down via a TCP RST packet. This can be the other end crashing (although from your logs that doesn't look to be the case here) or something like a firewall sending a RST. Do you have any firewall or packet filter in that network path? iptables anti-spoofing rules? > And this on my server - getpeername failed: Transport endpoint > is not connected". >From the failed traces: debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: getpeername failed: Transport endpoint is not connected debug1: get_remote_port failed Since this happens immediately after the server reexecs itself, another possiblity is that somehow the descriptors are being marked close-on-exec. You can test this theory by adding "-r" to sshd's command line to disable reexec. -- 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 andrei650816 at gmail.com Fri Dec 11 18:23:06 2015 From: andrei650816 at gmail.com (Andrey Klimentev) Date: Fri, 11 Dec 2015 10:23:06 +0300 Subject: sshd "getpeername failed: Transport endpoint is not connected" error In-Reply-To: References: Message-ID: Thanks for suggestion. That was, indeed, a problem on our network. Sorry for bothering you. BTW, "-r" option is not included in a man page, it doesn't seem to have any effect as well. 2015-12-11 5:47 GMT+03:00 Darren Tucker : > On Wed, Dec 9, 2015 at 7:43 PM, Andrey Klimentev wrote: >> Hello, everybody. >> >> I've recently encountered a problem with OpenSSH server. Could you >> help me to troubleshoot it? >> >> I've configured 2 IP interfaces[1]: one with a public IP adress and >> one with a private address. When I connect[2] through the public >> interface (ens34), SSH works fine, but when I connect[3] through the >> private interface (ens32), I receive a rather cryptic message on my >> client - "ssh_exchange_identification: read: Connection reset by >> peer". > > "reset by peer" usually means the TCP connection has been torn down > via a TCP RST packet. This can be the other end crashing (although > from your logs that doesn't look to be the case here) or something > like a firewall sending a RST. > > Do you have any firewall or packet filter in that network path? > iptables anti-spoofing rules? > >> And this on my server - getpeername failed: Transport endpoint >> is not connected". > > From the failed traces: > > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 > debug1: inetd sockets after dupping: 3, 3 > debug1: getpeername failed: Transport endpoint is not connected > debug1: get_remote_port failed > > Since this happens immediately after the server reexecs itself, > another possiblity is that somehow the descriptors are being marked > close-on-exec. You can test this theory by adding "-r" to sshd's > command line to disable reexec. > > -- > 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 a.afonyashin at madnet-team.ru Fri Dec 11 19:13:59 2015 From: a.afonyashin at madnet-team.ru (Alexander Afonyashin) Date: Fri, 11 Dec 2015 11:13:59 +0300 Subject: Support for ChallengeResponseAuthentication in Match section Message-ID: Hi, I'm using 2-factor authentication (pubkey+googe_authenticator) and have an issue with rsync. It's configured to use pubkey to authenticate to server so when google_authentication is bypassed by not creating .google_authenticator file for particular user (thanks to nullok option in PAM) it still sends to stderr "Authenticated with partial success." message although it succeeded. So idea is simple: disable 2-factor authentication for particular user/network. Regards, Alexander From nkadel at gmail.com Sat Dec 12 15:37:08 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 11 Dec 2015 23:37:08 -0500 Subject: Support for ChallengeResponseAuthentication in Match section In-Reply-To: References: Message-ID: On Fri, Dec 11, 2015 at 3:13 AM, Alexander Afonyashin wrote: > Hi, > > I'm using 2-factor authentication (pubkey+googe_authenticator) and > have an issue with rsync. It's configured to use pubkey to > authenticate to server so when google_authentication is bypassed by > not creating .google_authenticator file for particular user (thanks to > nullok option in PAM) it still sends to stderr "Authenticated with > partial success." message although it succeeded. > > So idea is simple: disable 2-factor authentication for particular user/network. > > Regards, > Alexander Put that access on a different port, with a different SSH daemon, is the fastest solution. From mfriedl at gmail.com Mon Dec 14 00:19:11 2015 From: mfriedl at gmail.com (Markus Friedl) Date: Sun, 13 Dec 2015 14:19:11 +0100 Subject: [feature request] Reverse socks proxy In-Reply-To: References: <56687B2B.4070205@gmail.com> Message-ID: <99B943BD-7BA9-4CB1-9614-52B5E4F15A17@gmail.com> Fwiw, I also have a patch for this, But unlike the client version it needs server support. > Am 09.12.2015 um 23:50 schrieb Darren Tucker : > > On Thu, Dec 10, 2015 at 6:04 AM, George Shuklin > wrote: >> Hello. >> >> OpenSSH has -D option to create socks proxy (take local traffic and send it >> from remote machine). But sometimes there is an opposite problem: to allow >> apps on remote machine send traffic from local machine (for example, to get >> access to intranet resources). > > There is an existing enhancement request for this with attached patch > (I have not looked at it in any detail or tried it though). > > https://bugzilla.mindrot.org/show_bug.cgi?id=2393 > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From tobiasu at tmux.org Mon Dec 14 11:44:19 2015 From: tobiasu at tmux.org (Tobias Ulmer) Date: Mon, 14 Dec 2015 01:44:19 +0100 Subject: Fix compilation if OpenSSL was configured with "no-rc4" Message-ID: <20151214004419.GA19272@tin.tmux.org> Fix compilation if OpenSSL was configured with "no-rc4" option. diff --git a/cipher.c b/cipher.c index 13847e5..00db675 100644 --- a/cipher.c +++ b/cipher.c @@ -90,9 +90,11 @@ static const struct sshcipher ciphers[] = { SSH_CIPHER_SSH2, 8, 16, 0, 0, 0, 1, EVP_bf_cbc }, { "cast128-cbc", SSH_CIPHER_SSH2, 8, 16, 0, 0, 0, 1, EVP_cast5_cbc }, +#ifndef OPENSSL_NO_RC4 { "arcfour", SSH_CIPHER_SSH2, 8, 16, 0, 0, 0, 0, EVP_rc4 }, { "arcfour128", SSH_CIPHER_SSH2, 8, 16, 0, 0, 1536, 0, EVP_rc4 }, { "arcfour256", SSH_CIPHER_SSH2, 8, 32, 0, 0, 1536, 0, EVP_rc4 }, +#endif { "aes128-cbc", SSH_CIPHER_SSH2, 16, 16, 0, 0, 0, 1, EVP_aes_128_cbc }, { "aes192-cbc", SSH_CIPHER_SSH2, 16, 24, 0, 0, 0, 1, EVP_aes_192_cbc }, { "aes256-cbc", SSH_CIPHER_SSH2, 16, 32, 0, 0, 0, 1, EVP_aes_256_cbc }, @@ -617,7 +619,7 @@ cipher_set_keyiv(struct sshcipher_ctx *cc, const u_char *iv) return 0; } -#ifdef WITH_OPENSSL +#if defined(WITH_OPENSSL) && !defined(OPENSSL_NO_RC4) #define EVP_X_STATE(evp) (evp).cipher_data #define EVP_X_STATE_LEN(evp) (evp).cipher->ctx_size #endif @@ -625,7 +627,7 @@ cipher_set_keyiv(struct sshcipher_ctx *cc, const u_char *iv) int cipher_get_keycontext(const struct sshcipher_ctx *cc, u_char *dat) { -#ifdef WITH_OPENSSL +#if defined(WITH_OPENSSL) && !defined(OPENSSL_NO_RC4) const struct sshcipher *c = cc->cipher; int plen = 0; @@ -644,7 +646,7 @@ cipher_get_keycontext(const struct sshcipher_ctx *cc, u_char *dat) void cipher_set_keycontext(struct sshcipher_ctx *cc, const u_char *dat) { -#ifdef WITH_OPENSSL +#if defined(WITH_OPENSSL) && !defined(OPENSSL_NO_RC4) const struct sshcipher *c = cc->cipher; int plen; From mdb at juniper.net Mon Dec 14 11:40:53 2015 From: mdb at juniper.net (Mark D. Baushke) Date: Sun, 13 Dec 2015 16:40:53 -0800 Subject: [Bug 2512] Use IP_FREEBIND if available for sshd listening socket In-Reply-To: References: Message-ID: <5244.1450053653@eng-mail01.juniper.net> writes: > https://bugzilla.mindrot.org/show_bug.cgi?id=2512 > --- Comment #1 from Damien Miller --- > Why can't systemd start sshd after the interfaces have been brought up? It is entirely possible for systemd to start sshd aftre the interfaces have been brought up or have it work in an inetd kind of way for each connection to port 22. Generally, one uses After=network.target or After=network-online.target and one may want a Wants=network-online.target or wait for the sshd-keygen.service to start first. An example might be: $ cat sshd.service [Unit] Description=OpenSSH server daemon Documentation=man:sshd(8) man:sshd_config(5) After=network.target sshd-keygen.service Wants=sshd-keygen.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target $ The use of sshd.socket also allows for inetd like functionality with systemd if that is what is needed. Good luck, -- Mark From a.afonyashin at madnet-team.ru Mon Dec 14 17:34:39 2015 From: a.afonyashin at madnet-team.ru (Alexander Afonyashin) Date: Mon, 14 Dec 2015 09:34:39 +0300 Subject: Support for ChallengeResponseAuthentication in Match section In-Reply-To: References: Message-ID: Hi Nico, Thanks for the idea. Regards, Alexander On Sat, Dec 12, 2015 at 7:37 AM, Nico Kadel-Garcia wrote: > On Fri, Dec 11, 2015 at 3:13 AM, Alexander Afonyashin > wrote: >> Hi, >> >> I'm using 2-factor authentication (pubkey+googe_authenticator) and >> have an issue with rsync. It's configured to use pubkey to >> authenticate to server so when google_authentication is bypassed by >> not creating .google_authenticator file for particular user (thanks to >> nullok option in PAM) it still sends to stderr "Authenticated with >> partial success." message although it succeeded. >> >> So idea is simple: disable 2-factor authentication for particular user/network. >> >> Regards, >> Alexander > > Put that access on a different port, with a different SSH daemon, is > the fastest solution. From imorgan at nas.nasa.gov Tue Dec 15 06:44:16 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 14 Dec 2015 11:44:16 -0800 Subject: Support for ChallengeResponseAuthentication in Match section In-Reply-To: References: Message-ID: <20151214194416.GB6834@linux124.nas.nasa.gov> On Fri, Dec 11, 2015 at 11:13:59 +0300, Alexander Afonyashin wrote: > Hi, > > I'm using 2-factor authentication (pubkey+googe_authenticator) and > have an issue with rsync. It's configured to use pubkey to > authenticate to server so when google_authentication is bypassed by > not creating .google_authenticator file for particular user (thanks to > nullok option in PAM) it still sends to stderr "Authenticated with > partial success." message although it succeeded. > > So idea is simple: disable 2-factor authentication for particular user/network. > Try KbdInteractiveAuthentication (which is supported in Match blocks) instead of ChallengeResponseAuthentication. -- Iain Morgan From dtucker at zip.com.au Tue Dec 15 10:11:46 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Dec 2015 10:11:46 +1100 Subject: Fix compilation if OpenSSL was configured with "no-rc4" In-Reply-To: <20151214004419.GA19272@tin.tmux.org> References: <20151214004419.GA19272@tin.tmux.org> Message-ID: On Mon, Dec 14, 2015 at 11:44 AM, Tobias Ulmer wrote: > Fix compilation if OpenSSL was configured with "no-rc4" option. Thanks. Unfortunately, while this will fix the compile errors it introduces a runtime failure: the server and client will still offer the rc4 algorithms in their proposals but will die if the other end selects them. We're working on fixing this (for rc4 and a couple of other ciphers) over at https://bugzilla.mindrot.org/show_bug.cgi?id=2466 -- 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 Tue Dec 15 10:02:40 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Dec 2015 10:02:40 +1100 Subject: sshd "getpeername failed: Transport endpoint is not connected" error In-Reply-To: References: Message-ID: On Fri, Dec 11, 2015 at 6:23 PM, Andrey Klimentev wrote: > Thanks for suggestion. That was, indeed, a problem on our network. > Sorry for bothering you. > > BTW, "-r" option is not included in a man page, We consider -r (and -R which is also used by the reexec code) to be implementation details that end users should not rely on. > it doesn't seem to have any effect as well. It does, but the effect is not user visible. Look for "send_rexec_state: done" in the debug output with and without -r. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From nkadel at gmail.com Tue Dec 15 15:09:43 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 14 Dec 2015 23:09:43 -0500 Subject: sshd "getpeername failed: Transport endpoint is not connected" error In-Reply-To: References: Message-ID: On Mon, Dec 14, 2015 at 6:02 PM, Darren Tucker wrote: > On Fri, Dec 11, 2015 at 6:23 PM, Andrey Klimentev > wrote: >> Thanks for suggestion. That was, indeed, a problem on our network. >> Sorry for bothering you. >> >> BTW, "-r" option is not included in a man page, > > We consider -r (and -R which is also used by the reexec code) to be > implementation details that end users should not rely on. So you refuse to document it at all, and insist that admins must read the source code? I've actually seen people do this, but it seems unfriendly. From jjelen at redhat.com Wed Dec 16 00:38:28 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 15 Dec 2015 14:38:28 +0100 Subject: OpenSSH accepted keys specification Message-ID: <567017D4.7090801@redhat.com> Hello list. Based on the current behavior of openssh tools, which are asking for passphrase even without recognizing the key type from header, I was searching for some specification, format or description of the key types accepted and handled by openssh, but without any success. Nor browsing source code helped. I tried several key types in both old or new formats, with or without passphrase, but if I removed header, openssh asked for the passphrase but was never able to decode the key. I am aware of the file [1] which describes new protocol format, but that one has strict header in specification. What is the reason behind decoding every blob received from a file, even if it does not have the proper header? I guess there are some historical reasons but I would like to get more information about this topic. (Background is discussion in our bug [2] about behavior of RSA1 keys with openssh compiled without RSA1 support, where I got to the dead end of my knowledge and of what I was able to find out myself.) [1] https://anongit.mindrot.org/openssh.git/tree/PROTOCOL.key [2] https://bugzilla.redhat.com/show_bug.cgi?id=1282423 Thank you in advance, -- Jakub Jelen Security Technologies Red Hat From a.afonyashin at madnet-team.ru Wed Dec 16 00:41:49 2015 From: a.afonyashin at madnet-team.ru (Alexander Afonyashin) Date: Tue, 15 Dec 2015 16:41:49 +0300 Subject: Support for ChallengeResponseAuthentication in Match section In-Reply-To: <20151214194416.GB6834@linux124.nas.nasa.gov> References: <20151214194416.GB6834@linux124.nas.nasa.gov> Message-ID: Hi Iain, Unfortunately it leads to "no authentication methods enabled" when is used. ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive Match User backup KbdInteractiveAuthentication no Ssh-ing to this config under user root: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: key at work debug1: Server accepts key: pkalg ssh-rsa blen 277 Authenticated with partial success. debug1: Authentications that can continue: keyboard-interactive debug1: Next authentication method: keyboard-interactive Verification code: Ssh-ing to this config under user backup: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received Received disconnect from X.X.X.X: 2: no authentication methods enabled Regards, Alexander On Mon, Dec 14, 2015 at 10:44 PM, Iain Morgan wrote: > On Fri, Dec 11, 2015 at 11:13:59 +0300, Alexander Afonyashin wrote: >> Hi, >> >> I'm using 2-factor authentication (pubkey+googe_authenticator) and >> have an issue with rsync. It's configured to use pubkey to >> authenticate to server so when google_authentication is bypassed by >> not creating .google_authenticator file for particular user (thanks to >> nullok option in PAM) it still sends to stderr "Authenticated with >> partial success." message although it succeeded. >> >> So idea is simple: disable 2-factor authentication for particular user/network. >> > > Try KbdInteractiveAuthentication (which is supported in Match blocks) > instead of ChallengeResponseAuthentication. > > -- > Iain Morgan From a.afonyashin at madnet-team.ru Wed Dec 16 00:56:20 2015 From: a.afonyashin at madnet-team.ru (Alexander Afonyashin) Date: Tue, 15 Dec 2015 16:56:20 +0300 Subject: Support for ChallengeResponseAuthentication in Match section In-Reply-To: References: <20151214194416.GB6834@linux124.nas.nasa.gov> Message-ID: Hi, Finally got it working (user backup requires only pubkey to authenticate, others - 2-way through PAM): ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive Match User backup AuthenticationMethods publickey Regards, Alexander On Tue, Dec 15, 2015 at 4:41 PM, Alexander Afonyashin wrote: > Hi Iain, > > Unfortunately it leads to "no authentication methods enabled" when is used. > > ChallengeResponseAuthentication yes > AuthenticationMethods publickey,keyboard-interactive > Match User backup > KbdInteractiveAuthentication no > > Ssh-ing to this config under user root: > > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: key at work > debug1: Server accepts key: pkalg ssh-rsa blen 277 > Authenticated with partial success. > debug1: Authentications that can continue: keyboard-interactive > debug1: Next authentication method: keyboard-interactive > Verification code: > > Ssh-ing to this config under user backup: > > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > Received disconnect from X.X.X.X: 2: no authentication methods enabled > > Regards, > Alexander > > On Mon, Dec 14, 2015 at 10:44 PM, Iain Morgan wrote: >> On Fri, Dec 11, 2015 at 11:13:59 +0300, Alexander Afonyashin wrote: >>> Hi, >>> >>> I'm using 2-factor authentication (pubkey+googe_authenticator) and >>> have an issue with rsync. It's configured to use pubkey to >>> authenticate to server so when google_authentication is bypassed by >>> not creating .google_authenticator file for particular user (thanks to >>> nullok option in PAM) it still sends to stderr "Authenticated with >>> partial success." message although it succeeded. >>> >>> So idea is simple: disable 2-factor authentication for particular user/network. >>> >> >> Try KbdInteractiveAuthentication (which is supported in Match blocks) >> instead of ChallengeResponseAuthentication. >> >> -- >> Iain Morgan From Kam.Nasim at windriver.com Thu Dec 17 09:34:11 2015 From: Kam.Nasim at windriver.com (Nasim, Kam) Date: Wed, 16 Dec 2015 22:34:11 +0000 Subject: Running sshd with Privilege Seperation drops connection on password change In-Reply-To: References: Message-ID: Hi Darren/Damien, Sorry for responding so late. Still hope we can get this sorted out. Yes I am indeed using PAM for ssh authentication and disabling priv seperation is a no-go for us since it opens up a security loophole. From what I can see in ptree and auth logs, when the child passwd process returns with SIGCHLD, the parent sshd process terminates. Sshd logs are as follows as requested at DEBUG3 verbosity. They indicate the ssh, followed by the password change and finally termination of connection: Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: monitor_read: checking request 12 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: PAM: sshpam_passwd_conv called with 1 messages Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: PAM: password authentication accepted for nasim Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_answer_authpassword: sending result 1 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_send entering: type 13 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive_expect entering: type 102 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive entering Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: do_pam_account: called Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: pam_unix(sshd:account): expired password for user nasim (root enforced) Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: PAM: sshpam_passwd_conv called with 1 messages Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: PAM: do_pam_account pam_acct_mgmt = 12 (Authentication token is no longer valid; new one required) Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: sshpam_password_change_required 1 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_send entering: type 103 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: Accepted password for nasim from 128.224.145.117 port 52060 ssh2 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: monitor_child_preauth: nasim has been authenticated by privileged process Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_get_keystate: Waiting for new keys Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive_expect entering: type 26 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive entering Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_newkeys_from_blob: 0x7f175498ad80(138) Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug2: mac_setup: setup hmac-md5-etm at openssh.com Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_get_keystate: Waiting for second key Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_newkeys_from_blob: 0x7f175498ad80(138) Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug2: mac_setup: setup hmac-md5-etm at openssh.com Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_get_keystate: Getting compression state Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_get_keystate: Getting Network I/O buffers Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_auth_password: user authenticated [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive entering [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_do_pam_account returning 1 [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_send_keystate: Sending new keys: 0x7f17549728f0 0x7f17549733a0 [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_newkeys_to_blob: converting 0x7f17549728f0 [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_newkeys_to_blob: converting 0x7f17549733a0 [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_send_keystate: New keys have been sent [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_send_keystate: Sending compression state [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_send entering: type 26 [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_send_keystate: Finished sending state [preauth] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: monitor_read_log: child log fd closed Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_share_sync: Share sync Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_share_sync: Share sync end Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: PAM: establishing credentials Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: PAM: opening session Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: pam_unix(sshd:session): session opened for user nasim by (uid=0) Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: PAM: sshpam_store_conv called with 1 messages Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: message repeated 2 times: [ debug3: PAM: sshpam_store_conv called with 1 messages] Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: User child is on pid 8623 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: SELinux support disabled Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: PAM: establishing credentials Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: permanently_set_uid: 1003/1003 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: set_newkeys: mode 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: set_newkeys: mode 1 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: Entering interactive session for SSH2. Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: fd 5 setting O_NONBLOCK Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: fd 6 setting O_NONBLOCK Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_init_dispatch_20 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: input_session_request Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: channel 0: new [server-session] Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: session_new: allocate (allocated 0 max 10) Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: session_unused: session id 0 unused Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_new: session 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_open: channel 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_open: session 0: link with channel 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_input_channel_open: confirm session Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_input_channel_req: channel 0 request pty-req reply 1 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_by_channel: session 0 channel 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_input_channel_req: session 0 req pty-req Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: Allocating pty. Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: mm_request_send entering: type 28 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive entering Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: monitor_read: checking request 28 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_answer_pty entering Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug2: session_new: allocate (allocated 0 max 10) Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: session_unused: session id 0 unused Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: session_new: session 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug1: SELinux support disabled Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_request_send entering: type 29 Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: mm_answer_pty: tty /dev/pts/1 ptyfd 4 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: mm_request_receive_expect entering: type 29 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: mm_request_receive entering Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_pty_req: session 0 alloc /dev/pts/1 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_input_channel_req: channel 0 request env reply 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_by_channel: session 0 channel 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_input_channel_req: session 0 req env Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: Setting env 0: LANG=en_US.UTF-8 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: server_input_channel_req: channel 0 request shell reply 1 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_by_channel: session 0 channel 0 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: session_input_channel_req: session 0 req shell Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: Starting session: shell on pts/1 for nasim from 128.224.145.117 port 52060 Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: fd 3 setting TCP_NODELAY Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: packet_set_tos: set IP_TOS 0x10 Dec 16 22:22:13 knasim-ubuntu1 sshd[8624]: debug1: Setting controlling tty using TIOCSCTTY. Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: channel 0: rfd 10 isatty Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug2: fd 10 setting O_NONBLOCK Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug3: fd 8 is O_NONBLOCK Dec 16 22:22:24 knasim-ubuntu1 passwd[8624]: pam_unix(passwd:chauthtok): password changed for nasim Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: Received SIGCHLD. Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: session_by_pid: pid 8624 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: session_exit_message: session 0 channel 0 pid 8624 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: request exit-status confirm 0 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: session_exit_message: release channel 0 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: write failed Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: close_write Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: send eow Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: output open -> closed Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug3: mm_request_send entering: type 30 Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive entering Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: monitor_read: checking request 30 Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: mm_answer_pty_cleanup entering Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug1: session_by_tty: session 0 tty /dev/pts/1 Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: mm_session_close: session 0 pid 8623 Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: mm_session_close: tty /dev/pts/1 ptyfd 4 Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug1: session_pty_cleanup: session 0 release /dev/pts/1 Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: session_unused: session id 0 unused Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: notify_done: reading Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: read<=0 rfd 10 len -1 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: read failed Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: close_read Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: input open -> drain Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: ibuf empty Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: send eof Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: input drain -> closed Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: send close Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug3: channel 0: will not send data after close Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: rcvd close Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug3: channel 0: will not send data after close Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: is dead Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: gc: notify user Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: session_by_channel: session 0 channel 0 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: session_close_by_channel: channel 0 child 0 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: session_close: session 0 pid 0 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug3: session_unused: session id 0 unused Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: gc: user detached Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: is dead Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug2: channel 0: garbage collecting Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: channel 0: free: server-session, nchannels 1 Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug3: channel 0: status: The following connections are open:\r\n #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)\r\n Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: Received disconnect from 128.224.145.117: 11: disconnected by user Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: do_cleanup Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug3: PAM: sshpam_thread_cleanup entering Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: mm_request_receive entering Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug1: do_cleanup Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug1: PAM: cleanup Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug1: PAM: closing session Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: pam_unix(sshd:session): session closed for user nasim Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug1: PAM: deleting credentials Dec 16 22:22:24 knasim-ubuntu1 sshd[8569]: debug3: PAM: sshpam_thread_cleanup entering Let me know what you guys think. Thanks, Kam -----Original Message----- From: dtucker at dtucker.net [mailto:dtucker at dtucker.net] On Behalf Of Darren Tucker Sent: December-06-15 11:48 PM To: Nasim, Kam Cc: openssh-unix-dev at mindrot.org Subject: Re: Running sshd with Privilege Seperation drops connection on password change There's 3 ways that sshd will force you to change an expired password when you have PAM enabled (which you do): 1) if you're using keyboard-interactive authentication, sshd will call pam_chauthtok() as part of the authentication. This should work with or without privsep. If you authenticate some other way (eg password), sshd will force you to change your password once you start your session. 2) if you have privilege separation enabled, by the time your session starts sshd has dropped the privileges needed to successfully call pam_chauthtok(). Instead, it'll exec /bin/passwd. 3) if you have privsep disabled, sshd is still running as root and will call pam_chauthtok(). On Sat, Dec 5, 2015 at 3:23 AM, Nasim, Kam wrote: [...] > PROBLEM: > If I expire a linux user's password (passwd -e ) and then log in via ssh, it will prompt you for a password change. > On changing the password successfully, sshd will drop the connection and client has to reconnect. That's working as intended, and you should have seen text to that effect. In session.c (simplified): static void do_pwchange(Session *s) { fprintf(stderr, "WARNING: Your password has expired.\n"); if (s->ttyfd != -1) { fprintf(stderr, "You must change your password now and login again!\n"); execl(_PATH_PASSWD_PROG, "passwd", (char *)NULL); > If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication. RIght, see #3 above. -- 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. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: December-06-15 11:16 PM To: Nasim, Kam Cc: openssh-unix-dev at mindrot.org Subject: Re: Running sshd with Privilege Seperation drops connection on password change Hi, We'll need to see a full debug log from the server - it's not possible to see what is going one from the abridged ones you sent. -d On Fri, 4 Dec 2015, Nasim, Kam wrote: > Hi folks, > > I came across this issue on both stock CentOS(v6.4) and Ubuntu(14.04 LTS) and was wondering if any of you have seen it. > As far as I can tell this seems like a day-1 bug to me. > > PROBLEM: > If I expire a linux user's password (passwd -e ) and then log in via ssh, it will prompt you for a password change. > On changing the password successfully, sshd will drop the connection and client has to reconnect. > > > ANALYSIS: > > Looking at sshd debug logs, it would appear that the child process that runs passwd SIGCHLD's to the parent which appears to be treating that signal as a SIGTERM: > > Dec 3 18:36:17 knasim-ubuntu1 passwd[3152]: > pam_unix(passwd:chauthtok): password changed for wrs <<<<<<< Dec 3 > 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: Received SIGCHLD. > <<<<<<<<<<<<<<<<<< Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: > session_by_pid: pid 3152 Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: > debug1: session_exit_message: session 0 channel 0 pid 3152 Dec 3 > 18:36:17 knasim-ubuntu1 sshd[3151]: debug2: channel 0: request > exit-status confirm 0 <<<<<<<<<<< > > > By default, in sshd "Privilege Separation" is enabled. What does this mean? > > It means that sshd spawns an unprivileged process that does basic authentication and that guy spawns a child process running as root to run passwd (in this case). > > After password change, the child SIGCHLD's the parent which instead of handling it properly treats it like a SIGTERM and closes the socket. > > The following process tree should give a better idea of the process nestings: > > With Privilege Separation: > ubuntu at knasim-ubuntu1:~$ pstree > init???acpid > ??atd > ??cron > ??dbus-daemon > ??dhclient > ??7*[getty] > ??rsyslogd???3*[{rsyslogd}] > ??sshd???bash???ssh > ??sshd???bash???pstree > ??sshd???sshd???sshd???passwd > ??systemd-logind > ??systemd-udevd > ??upstart-file-br > ??upstart-socket- > ??upstart-udev-br > > Without Privilege Separation: > init???acpid > ??atd > ??cron > ??dbus-daemon > ??dhclient > ??7*[getty] > ??rsyslogd???3*[{rsyslogd}] > ??sshd???sshd???bash???ssh > ? ??sshd???bash???pstree > ? ??sshd???sshd > ??systemd-logind > ??systemd-udevd > ??upstart-file-br > ??upstart-socket- > ??upstart-udev-br > > If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication. > > > What do you guys think? Have others come across this? Is there a patch available for this? > > Thanks, > Kam > _______________________________________________ > 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 Dec 17 10:09:16 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Dec 2015 10:09:16 +1100 Subject: Running sshd with Privilege Seperation drops connection on password change In-Reply-To: References: Message-ID: On Thu, Dec 17, 2015 at 9:34 AM, Nasim, Kam wrote: > Hi Darren/Damien, > > Sorry for responding so late. Still hope we can get this sorted out. > Yes I am indeed using PAM for ssh authentication and disabling priv seperation is a no-go for us since it opens up a security loophole. > > From what I can see in ptree and auth logs, when the child passwd process returns with SIGCHLD, the parent sshd process terminates. > > Sshd logs are as follows as requested at DEBUG3 verbosity. They indicate the ssh, followed by the password change and finally termination of connection: Despite being asked for them earlier, you still have not provided the full debug logs, which would tell, amongst other things, what version of OpenSSH this is. That said... [...] > Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: SELinux support disabled I know of no version of OpenSSH supplied by us that has that message, so I suspect you are using a modified version. > Dec 16 22:22:13 knasim-ubuntu1 sshd[8569]: debug3: PAM: sshpam_passwd_conv called with 1 messages [...] > Dec 16 22:22:24 knasim-ubuntu1 passwd[8624]: pam_unix(passwd:chauthtok): password changed for nasim This is working exactly as I described in option #2 earlier: password authentication followed by execing /bin/passwd. Your other option is what I described in #1: Disable PasswordAuthentication in sshd_config and use ChallengeResponseAuthentication/KbdInteractiveAuthentication. > Dec 16 22:22:24 knasim-ubuntu1 sshd[8623]: debug1: Received SIGCHLD. [...] > Let me know what you guys think. I think it is working as intended. -- 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 jjelen at redhat.com Thu Dec 17 20:36:02 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Thu, 17 Dec 2015 10:36:02 +0100 Subject: Running sshd with Privilege Seperation drops connection on password change In-Reply-To: References: Message-ID: <56728202.8060200@redhat.com> On 12/17/2015 12:09 AM, Darren Tucker wrote: > On Thu, Dec 17, 2015 at 9:34 AM, Nasim, Kam wrote: >> Dec 16 22:22:13 knasim-ubuntu1 sshd[8623]: debug1: SELinux support disabled > I know of no version of OpenSSH supplied by us that has that message, > so I suspect you are using a modified version. FYI, it is part of port-linux.c: https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/port-linux.c#n53 > On changing the password successfully, sshd will drop the connection and client has to reconnect. Yes, this is intended behavior and described in the message to user before prompting for password: https://anongit.mindrot.org/openssh.git/tree/session.c#n1578 Without privilege separation, there is though some problem that the connection is NOT dropped, if I remember well, but I consider this as a low-priority, since it is not advised to use ssh without privilege separation. -- Jakub Jelen Security Technologies Red Hat From laszlo.attila.toth at balabit.com Sat Dec 19 01:12:38 2015 From: laszlo.attila.toth at balabit.com (=?UTF-8?B?VMOzdGgsIEzDoXN6bMOzIEF0dGlsYQ==?=) Date: Fri, 18 Dec 2015 15:12:38 +0100 Subject: Portalbe OpenSSH's don't know agent's keys after authenticion failure with partial success Message-ID: Hi, If SSH_MSG_USERAUTH_FAILURE arrives from the server with partial success (set to 1), in input_userauth_failure() the pubkey_cleanup() and pubkey_prepare() calls does different thing than the first pubkey_prepare() instead of identical. OpenSSH versions: 6.7p1 to 7.1p1 (based on changelog the issue seems to be introduced in 6.3p1 during fixing another bug): * ssh(1): reset the order in which public keys are tried after partial authentication success. Environment: * an ssh-agent with a passphrase-protected private key stored in its standard name (e.g. .ssh/id_rsa) * a server that accepts this key but requires further authentication (auth failure with partial success) * and the ssh client First the client sends the key stored in the agent, and then clears its keys in authctx, and retries the keys. At this point the public key is missing (.ssh/id_rsa), therefore ssh tries to ask the passphrase, even if the key is loaded into the agent. And if the passphrase is given, it retries the very same key. The problem seems to be occured in pubkey_prepare(), in this line: options.identity_keys[i] = NULL; If the code wants to iterate thrugh these keys after a partial success, these keys should never be NULL'ed, instead these should be copied. As a result, if I'm not mistaken, the ssh client skips all keys of the agent. Regrads, Laszlo Attila TOTH From klewis at republictt.com Thu Dec 24 01:20:52 2015 From: klewis at republictt.com (Kevin Lewis) Date: Wed, 23 Dec 2015 10:20:52 -0400 Subject: OpenSSH-7.1p1 Message-ID: <1450880452610583789@republictt.com> Good day, I am in the process of installing OpenSSH-7.1p1 on a test AIX Unix box. I would like to know how to uninstall or remove this package if the need arises. Can this package be overwritten with a previous package, let's say OpenSSH-6.9p1, or any previous version? Regards, Kevin S. Lewis | Technical Support Analyst, Production Support | Information Technology Management Division | Republic Bank Limited | 49-51 Pembroke Street | Port of Spain | Trinidad and Tobago ( 868-625-3617 Ext. 2641 | 6 868-624-0187 | * klewis at republictt.com | 8 http://www.republictt.com Email-Signature---Black-call-to-action (3) The information contained in this e-mail transmission is confidential and may be privileged. If you are not the intended recipient you are hereby notified that any use, dissemination or copying of this transmission (including any attachments) is strictly prohibited. If you have received this e-mail in error please notify the sender immediately by e-mail reply and then delete it from your system. The information contained in this e-mail transmission is confidential and may be privileged. If you are not the intended recipient you are hereby notified that any use, dissemination or copying of this transmission (including any attachments) is strictly prohibited. If you have received this e-mail in error please notify the sender immediately by e-mail reply and then delete it from your system. From alon.barlev at gmail.com Thu Dec 24 02:13:16 2015 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 23 Dec 2015 17:13:16 +0200 Subject: Why hostkeys-00@openssh.com is following user authentication? Message-ID: Hello, This hostkeys extension is great, reading[1]: """ OpenSSH supports a protocol extension allowing a server to inform a client of all its protocol v.2 host keys after user-authentication has completed. """ I wonder, why should user authentication be completed before this functionality is available? This means that ssh-keyscan tool (for example) cannot take advantage of the functionality. The only reason I could think of (apart of sshd internal implementation ordering) is to avoid cpu load attack of anonymous clients forcing server to perform expensive operations. However, a similar attack can be achieved by multiple connections and/or re-kex. In sshd.c I see hostkeys-00 at openssh.com sent before calling do_authenticated(), so I even more curios. Thanks! Alon Bar-Lev. [1] https://github.com/openssh/openssh-portable/blob/master/PROTOCOL#L284 From peter at stuge.se Thu Dec 24 02:34:44 2015 From: peter at stuge.se (Peter Stuge) Date: Wed, 23 Dec 2015 16:34:44 +0100 Subject: OpenSSH-7.1p1 In-Reply-To: <1450880452610583789@republictt.com> References: <1450880452610583789@republictt.com> Message-ID: <20151223153444.20438.qmail@stuge.se> Hi Kevin, Kevin Lewis wrote: > I am in the process of installing OpenSSH-7.1p1 on a test AIX Unix > box. I would like to know how to uninstall or remove this package > if the need arises. That would be the job of a package manager. I don't know if there is one commonly available on AIX. Because OpenSSH-portable uses automake you can do it pretty easily yourself too. The generated Makefiles have a make uninstall target, like the thousands other packages which use automake. The uninstall target might not remove every single file, especially not configuration files or files created by either server or client as they are being used. Also thanks to automake, you can do a dummy install into any destination directory on the system with make install DESTDIR=/some/path > Can this package be overwritten with a previous package, let's say > OpenSSH-6.9p1, or any previous version? Sure, you can install on top. There might still be some files left-over from the newer version which are not provided by the older version, one example would be host keys for algorithms only used by the newer version. They would not be overwritten and of course not deleted. The older version would also not use them. > The information contained in this e-mail transmission is confidential > and may be privileged. The bank should stop claiming that it transmits confidential email to open mailing lists known to be publically archived. It looks bad. //Peter From djm at mindrot.org Thu Dec 24 08:30:44 2015 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Dec 2015 08:30:44 +1100 (AEDT) Subject: Why hostkeys-00@openssh.com is following user authentication? In-Reply-To: References: Message-ID: On Wed, 23 Dec 2015, Alon Bar-Lev wrote: > Hello, > > This hostkeys extension is great, reading[1]: > """ > OpenSSH supports a protocol extension allowing a server to inform a > client of all its protocol v.2 host keys after user-authentication has > completed. > """ > > I wonder, why should user authentication be completed before this > functionality is available? This means that ssh-keyscan tool (for > example) cannot take advantage of the functionality. It's done this way because the only extensible messages in the protocol are channel and global requests, which are only valid after the "ssh-connection" (channels) service has been requested. This only happens after userauth. It would be better to do it after key exchange and before user authentication, but it would also be less compatible with other implementations. -d From alon.barlev at gmail.com Thu Dec 24 17:12:33 2015 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 24 Dec 2015 08:12:33 +0200 Subject: Why hostkeys-00@openssh.com is following user authentication? In-Reply-To: References: Message-ID: On 23 December 2015 at 23:30, Damien Miller wrote: > > On Wed, 23 Dec 2015, Alon Bar-Lev wrote: > > > Hello, > > > > This hostkeys extension is great, reading[1]: > > """ > > OpenSSH supports a protocol extension allowing a server to inform a > > client of all its protocol v.2 host keys after user-authentication has > > completed. > > """ > > > > I wonder, why should user authentication be completed before this > > functionality is available? This means that ssh-keyscan tool (for > > example) cannot take advantage of the functionality. > > It's done this way because the only extensible messages in the protocol > are channel and global requests, which are only valid after the > "ssh-connection" (channels) service has been requested. This only happens > after userauth. > > It would be better to do it after key exchange and before user > authentication, but it would also be less compatible with other > implementations. > > -d Thank you for quick response! I was under the impression that global requests can be sent before user authentication. From carl at stripe.com Wed Dec 30 10:23:52 2015 From: carl at stripe.com (Carl Jackson) Date: Tue, 29 Dec 2015 18:23:52 -0500 Subject: Bug in KRL signature verification Message-ID: I believe there has been a bug in KRL signature verification that has been present since the KRL feature was first introduced. It prevents signed KRLs from being loaded by OpenSSH [0]. I believe this bug applies to all versions of OpenSSH, although the majority of my effort has been devoted to (and all of my code snippets come from) openssl-portable. The bug is that an offset is incorrectly treated as a length [2]: /* Check signature over entire KRL up to this point */ > if ((r = sshkey_verify(key, blob, blen, > sshbuf_ptr(buf), sshbuf_len(buf) - sig_off, 0)) != 0) > goto out; "sshbuf_len(buf) - sig_off" should read "sig_off". The result of this bug is that the number of unparsed bytes after our current parse cursor, rather than the number of parsed bytes before the cursor, is used as the length of the data to be verified. I don't believe this bug has any security implications, though, since both lengths are necessarily smaller than the length of buf. Fixing this bug uncovers another bug in ssh_krl_from_blob [3]: "if (sshbuf_len(sect) > 0)" should read "if (sect != NULL && sshbuf_len(sect) > 0)" (or similar), since a KRL_SECTION_SIGNATURE above might cause sect to be set to NULL. This bug results in a segmentation fault, but I don't believe it can be triggered without first fixing the above bug. In case anyone is interested in testing this behavior out, I believe the following hex-encoded string to be a spec-compliant [1] signed KRL: 5353484b524c0a00000000010000000043b9a3550000000043b9a3550000000000000000000000000000000001000000ac00000097000000077373682d727361000000030100010000008100aa28507872c5898cc95419d513f42a4b705fa0a212c5c8684d520375d88c5cb0d29cedb572cba9b07475e96e363511e7b0fb585ee9a3cc58db411abc3cd6e7c26d7d042a2ce842bd7af40522798680b9f1a54fdb598a80a170153995c8e3e63d411af5d436fdf2b9675c2e4bb3cc235a03e7f1955386aa5211ba919ecfb4137700000000200000000800000000000024520400000097000000077373682d727361000000030100010000008100aa28507872c5898cc95419d513f42a4b705fa0a212c5c8684d520375d88c5cb0d29cedb572cba9b07475e96e363511e7b0fb585ee9a3cc58db411abc3cd6e7c26d7d042a2ce842bd7af40522798680b9f1a54fdb598a80a170153995c8e3e63d411af5d436fdf2b9675c2e4bb3cc235a03e7f1955386aa5211ba919ecfb413770000008f000000077373682d727361000000801f3e023a97e606f90085bf09c11bc97ac1ef5ae2a8838d294c182f4d5201c3c9ed30d50c7f010a3f3b7aafb01d4b41b3b7afc33769638841c191d6661be995b310db6d4b90f4291a8a69d079d95bd6e9687ae96b4be58154a13f56680439ce4165170e219168db0ade9f4623b674dc4ff99498388b8344628d9662be3b4c75c0 It revokes a single certificate with serial 9298 issued by the following authority: ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAAAgQCqKFB4csWJjMlUGdUT9CpLcF+gohLFyGhNUgN12IxcsNKc7bVyy6mwdHXpbjY1Eeew+1he6aPMWNtBGrw81ufCbX0EKizoQr169AUieYaAufGlT9tZioChcBU5lcjj5j1BGvXUNv3yuWdcLkuzzCNaA+fxlVOGqlIRupGez7QTdw== The KRL also has a single signature from this authority. Carl [0]: OpenSSH itself never produces signed KRLs, and so far as I've been able to tell nobody else does either. I found this while adding KRL support based on the spec [1] to Go (golang)'s x/crypto/ssh package. [1]: https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/PROTOCOL.krl [2]: https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/krl.c#L1010-L1019 [3]: https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/krl.c#L1095-L1104 From carl at stripe.com Wed Dec 30 13:57:50 2015 From: carl at stripe.com (Carl Jackson) Date: Tue, 29 Dec 2015 21:57:50 -0500 Subject: Bug in KRL signature verification In-Reply-To: References: Message-ID: There seems to be at least one more bug with KRL signature verification: the first pass loop that gathers signatures terminates after the first signature [0]. I think removing the "break" at the end of the loop is sufficient to fix this behavior for KRLs signed multiple times. Carl [0]: https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/krl.c#L1039 On Tue, Dec 29, 2015 at 6:23 PM, Carl Jackson wrote: > I believe there has been a bug in KRL signature verification that has been > present since the KRL feature was first introduced. It prevents signed KRLs > from being loaded by OpenSSH [0]. I believe this bug applies to all > versions of OpenSSH, although the majority of my effort has been devoted to > (and all of my code snippets come from) openssl-portable. > > The bug is that an offset is incorrectly treated as a length [2]: > > /* Check signature over entire KRL up to this point */ >> if ((r = sshkey_verify(key, blob, blen, >> sshbuf_ptr(buf), sshbuf_len(buf) - sig_off, 0)) != 0) >> goto out; > > > "sshbuf_len(buf) - sig_off" should read "sig_off". The result of this bug > is that the number of unparsed bytes after our current parse cursor, rather > than the number of parsed bytes before the cursor, is used as the length of > the data to be verified. I don't believe this bug has any security > implications, though, since both lengths are necessarily smaller than the > length of buf. > > Fixing this bug uncovers another bug in ssh_krl_from_blob [3]: "if > (sshbuf_len(sect) > 0)" should read "if (sect != NULL && sshbuf_len(sect) > > 0)" (or similar), since a KRL_SECTION_SIGNATURE above might cause sect to > be set to NULL. This bug results in a segmentation fault, but I don't > believe it can be triggered without first fixing the above bug. > > In case anyone is interested in testing this behavior out, I believe the > following hex-encoded string to be a spec-compliant [1] signed KRL: > > >> 5353484b524c0a00000000010000000043b9a3550000000043b9a3550000000000000000000000000000000001000000ac00000097000000077373682d727361000000030100010000008100aa28507872c5898cc95419d513f42a4b705fa0a212c5c8684d520375d88c5cb0d29cedb572cba9b07475e96e363511e7b0fb585ee9a3cc58db411abc3cd6e7c26d7d042a2ce842bd7af40522798680b9f1a54fdb598a80a170153995c8e3e63d411af5d436fdf2b9675c2e4bb3cc235a03e7f1955386aa5211ba919ecfb4137700000000200000000800000000000024520400000097000000077373682d727361000000030100010000008100aa28507872c5898cc95419d513f42a4b705fa0a212c5c8684d520375d88c5cb0d29cedb572cba9b07475e96e363511e7b0fb585ee9a3cc58db411abc3cd6e7c26d7d042a2ce842bd7af40522798680b9f1a54fdb598a80a170153995c8e3e63d411af5d436fdf2b9675c2e4bb3cc235a03e7f1955386aa5211ba919ecfb413770000008f000000077373682d727361000000801f3e023a97e606f90085bf09c11bc97ac1ef5ae2a8838d294c182f4d5201c3c9ed30d50c7f010a3f3b7aafb01d4b41b3b7afc33769638841c191d6661be995b310db6d4b90f4291a8a69d079d95bd6e9687ae96b4be58154a13f56680439ce4165170e219168db0ade9f4623b674dc4ff99498388b8344628d9662be3b4c75c0 > > > It revokes a single certificate with serial 9298 issued by the following > authority: > > ssh-rsa >> AAAAB3NzaC1yc2EAAAADAQABAAAAgQCqKFB4csWJjMlUGdUT9CpLcF+gohLFyGhNUgN12IxcsNKc7bVyy6mwdHXpbjY1Eeew+1he6aPMWNtBGrw81ufCbX0EKizoQr169AUieYaAufGlT9tZioChcBU5lcjj5j1BGvXUNv3yuWdcLkuzzCNaA+fxlVOGqlIRupGez7QTdw== > > > The KRL also has a single signature from this authority. > > Carl > > [0]: OpenSSH itself never produces signed KRLs, and so far as I've been > able to tell nobody else does either. I found this while adding KRL support > based on the spec [1] to Go (golang)'s x/crypto/ssh package. > [1]: > https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/PROTOCOL.krl > [2]: > https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/krl.c#L1010-L1019 > [3]: > https://github.com/openssh/openssh-portable/blob/271df8185d9689b3fb0523f58514481b858f6843/krl.c#L1095-L1104 > From djm at mindrot.org Thu Dec 31 11:30:21 2015 From: djm at mindrot.org (Damien Miller) Date: Thu, 31 Dec 2015 11:30:21 +1100 (AEDT) Subject: Bug in KRL signature verification In-Reply-To: References: Message-ID: On Tue, 29 Dec 2015, Carl Jackson wrote: > There seems to be at least one more bug with KRL signature verification: > the first pass loop that gathers signatures terminates after the first > signature [0]. I think removing the "break" at the end of the loop is > sufficient to fix this behavior for KRLs signed multiple times. Thanks for the detailed reports. Here are the fixes that I made - I'll commit them shortly. Please let me know if you end up making any more test KRLs for your work on the Go implementation, I might add them to our test suite. -d Index: krl.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/krl.c,v retrieving revision 1.36 diff -u -p -r1.36 krl.c --- krl.c 11 Dec 2015 04:21:12 -0000 1.36 +++ krl.c 30 Dec 2015 23:41:06 -0000 @@ -1013,7 +1013,7 @@ ssh_krl_from_blob(struct sshbuf *buf, st } /* Check signature over entire KRL up to this point */ if ((r = sshkey_verify(key, blob, blen, - sshbuf_ptr(buf), sshbuf_len(buf) - sig_off, 0)) != 0) + sshbuf_ptr(buf), sig_off, 0)) != 0) goto out; /* Check if this key has already signed this KRL */ for (i = 0; i < nca_used; i++) { @@ -1034,7 +1034,6 @@ ssh_krl_from_blob(struct sshbuf *buf, st ca_used = tmp_ca_used; ca_used[nca_used++] = key; key = NULL; - break; } if (sshbuf_len(copy) != 0) { @@ -1099,7 +1098,7 @@ ssh_krl_from_blob(struct sshbuf *buf, st r = SSH_ERR_INVALID_FORMAT; goto out; } - if (sshbuf_len(sect) > 0) { + if (sect != NULL && sshbuf_len(sect) > 0) { error("KRL section contains unparsed data"); r = SSH_ERR_INVALID_FORMAT; goto out; From kaleb at wolfssl.com Tue Dec 29 04:37:57 2015 From: kaleb at wolfssl.com (Kaleb Himes) Date: Mon, 28 Dec 2015 17:37:57 -0000 Subject: wolfSSL port to openSSH Message-ID: Greetings OpenSSH developers, wolfSSL now has a stable port for any interested we are nearly ready to submit a pull request to openssh-portable repository. For any and all interested we are ready for some alpha testing. Testing should be as easy as doing the following steps: git clone https://github.com/kaleb-himes/openssh-portable.git git clone https://github.com/kaleb-himes/wolfssl.git cd wolfssl ./autogen.sh ./configure --prefix=/usr/local/lib --enable-openssh && make && sudo make install cd .. cd openssh-portable autoreconf ./configure --with-wolfssl=/usr/local/lib --with-pam && make && make tests Our Jenkins server is now using this port to actively checkout changes from github and is also running all slave nodes using SSH with this port. This provides us with some real-world testing in addition to the unit tests. We would ask for any feedback on our port from the openSSH community and welcome any questions before we submit a pull request to you in the near future. Thank you all for your time and consideration in this matter, we look forward to hearing from you. Our sincerest Regards, The wolfSSL Team and Kaleb Himes www.wolfssl.com kaleb at wolfssl.com Skype: kaleb.himes +1 406 381 9556