From djm at mindrot.org Sat Mar 1 09:15:07 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 1 Mar 2014 09:15:07 +1100 (EST) Subject: loginrec.c: bug in construct_utmpx() definition? In-Reply-To: <1393257358.85261.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <1393257358.85261.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: could you file a bug for this at https://bugzilla.mindrot.org/ ? Thanks, Damien On Mon, 24 Feb 2014, Paun Bogdan-Alexandru wrote: > Hello, > > I am trying to cross compile OpenSSH_5.8p2 on linux for a powerpc target with uClibc available. My problem is that I get a error when loginrec.c is compiled: > > openssh/loginrec.c: In function 'construct_utmpx': > openssh/loginrec.c:790:10: error: 'ut' undeclared (first use in this function) > openssh/loginrec.c:790:10: note: each undeclared identifier is reported only once for each function it appears in > > > My uClibc config includes support for UTMPX. > > Looking in openssh/loginrec.c at the mentioned line I see that 'ut' structure pointer name is used when HAVE_ADDR_V6_IN_UTMP is defined while in in the rest of the function only 'utx' is used. For my inexperienced coding skills this looks like a bug, wrong variable name 'ut' is used over 'utx'. > Changing that code to use 'utx' instead of of 'ut' will lead to a successful compilation of the whole SSH package. > I checked and that chunk of code is still unchanged in OpenSSH_6.5p1. > > However I am not sure if my attempt to fix the error is the correct way so I would really appreciate if someone could help me with this. > > Thanks for this great software, > Bogdan Paun > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Sat Mar 1 09:19:09 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 1 Mar 2014 09:19:09 +1100 (EST) Subject: Bug: Environment vars are changed before use (locale LANG, LC_*) In-Reply-To: <530CC263.1000106@wieschiolek.de> References: <530CC263.1000106@wieschiolek.de> Message-ID: On Tue, 25 Feb 2014, Carsten Wieschiolek wrote: > > Hi > > I am using > > OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013 > > on a Ubuntu 13.10 release for access to various kinds of systems. This > recent Ubuntu OS insists on standard conforming locales, i.e. > de_DE.UTF-8 instead of de_DE.utf8 as in the previous release. When I am > using SSH to communicate with another system not being able to process > the standard conformant setting (in my case HP-UX B.11.31), problems > arise, because the new setting cannot be processed. Even when I am > specifying the variable in the environment file of SSH in a form usable > by the remote system, they are changed into the standard conformant > setting first, before being transferred. This is a bug, because these > environment variables are intended to be processed on the remote system > as given in the local file. SSH should keep the values in the original > format specified and rely on translation by the remote system. It is > pointless to use setlocale(3) locally. OpenSSH doesn't perform any transformation of environment variables that are forwarded. Some possibilities: * your vendor included a patch to transform these environment variables * the enviornment variables are being overridden by PAM (see https://bugzilla.mindrot.org/show_bug.cgi?id=1346 ) * they are being overridden by a shell initialisation file (e.g. .bash_profile) -d From djm at mindrot.org Sat Mar 1 09:19:46 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 1 Mar 2014 09:19:46 +1100 (EST) Subject: Call for testing: OpenSSH 6.6 Message-ID: Hi, OpenSSH 6.6 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a small release mostly to fix some minor but annoying bugs in openssh-6.5. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs or via Git at https://anongit.mindrot.org/openssh.git/ Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Changes since OpenSSH 6.5 ========================= This is primarily a bugfix release. New / changed features: * ssh(1), sshd(8): this release removes the J-PAKE authentication code. This code was experimental, never enabled and had been unmaintained for some time. * ssh(1): when processing Match blocks, skip 'exec' clauses other clauses predicates failed to match. * ssh(1): if hostname canonicalisation is enabled and results in the destination hostname being changed, then re-parse ssh_config(5) files using the new destination hostname. This gives 'Host' and 'Match' directives that use the expanded hostname a chance to be applied. Bugfixes: * ssh(1): avoid spurious "getsockname failed: Bad file descriptor" in ssh -W. bz#2200, debian#738692 * sshd(8): allow the shutdown(2) syscall in seccomp-bpf and systrace sandbox modes, as it is reachable if the connection is terminated during the pre-auth phase. * ssh(1), sshd(8): fix unsigned overflow that in SSH protocol 1 bignum parsing. Minimum key length checks render this bug unexploitable to compromise SSH 1 sessions. * sshd_config(5): clarify behaviour of a keyword that appears in multiple matching Match blocks. bz#2184 * ssh(1): avoid unnecessary hostname lookups when canonicalisation is disabled. bz#2205 * sshd(8): avoid sandbox violation crashes in GSSAPI code by caching the supported list of GSSAPI mechanism OIDs before entering the sandbox. bz#2107 * ssh(1): fix possible crashes in SOCKS4 parsing caused by assumption that the SOCKS username is nul-terminated. * ssh(1): fix regression for UsePrivilegedPort=yes when BindAddress is not specified. * ssh(1), sshd(8): fix memory leak in ECDSA signature verification. * ssh(1): fix matching of 'Host' directives in ssh_config(5) files to be case-sensitive again (regression in 6.5). Portable OpenSSH: * sshd(8): don't fatal if the FreeBSD Capsicum is offered by the system headers and libc but is not supported by the kernel. * Fix build using the HP-UX compiler. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From htodd at twofifty.com Sat Mar 1 16:15:49 2014 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 28 Feb 2014 21:15:49 -0800 (PST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: I'm not sure if I'm supposed to be testing yet, but since I'm the pesky NetBSD guy, I did: git clone https://github.com/openssh/openssh-portable/ and after the autoreconf && ./configure && make tests, I got: run test dhgex.sh ... dhgex bits 3072 diffie-hellman-group-exchange-sha1 cast128-cbc FATAL: dhgex expected 3072 bit group, got 2048 *** Error code 1 Stop. make[1]: stopped in /home/htodd/openssh-portable/regress *** Error code 1 Stop. make: stopped in /home/htodd/openssh-portable -- Hisashi T Fujinaka - htodd at twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte From loganaden at gmail.com Sat Mar 1 16:38:20 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Sat, 1 Mar 2014 09:38:20 +0400 Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: Test on my OpenBSD desktop machine: OpenBSD logan.my.domain 5.4 GENERIC.MP#41 amd64 run test dhgex.sh ... dhgex bits 3072 diffie-hellman-group-exchange-sha1 cast128-cbc FATAL: dhgex expected 3072 bit group, got 2048 *** Error 1 in regress (Makefile:172 't-exec': @if [ "xconnect.sh proxy-connect.sh connect-privsep.sh proto-version.sh proto-mismatch.sh exi...) *** Error 1 in /home/logan/openssh_snap/openssh (Makefile:454 'tests') On Sat, Mar 1, 2014 at 2:19 AM, Damien Miller wrote: > Hi, > > OpenSSH 6.6 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is a small release > mostly to fix some minor but annoying bugs in openssh-6.5. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Git at https://anongit.mindrot.org/openssh.git/ > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the ChangeLog > in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > Changes since OpenSSH 6.5 > ========================= > > This is primarily a bugfix release. > > New / changed features: > > * ssh(1), sshd(8): this release removes the J-PAKE authentication code. > This code was experimental, never enabled and had been unmaintained > for some time. > > * ssh(1): when processing Match blocks, skip 'exec' clauses other clauses > predicates failed to match. > > * ssh(1): if hostname canonicalisation is enabled and results in the > destination hostname being changed, then re-parse ssh_config(5) files > using the new destination hostname. This gives 'Host' and 'Match' > directives that use the expanded hostname a chance to be applied. > > Bugfixes: > > * ssh(1): avoid spurious "getsockname failed: Bad file descriptor" in > ssh -W. bz#2200, debian#738692 > > * sshd(8): allow the shutdown(2) syscall in seccomp-bpf and systrace > sandbox modes, as it is reachable if the connection is terminated > during the pre-auth phase. > > * ssh(1), sshd(8): fix unsigned overflow that in SSH protocol 1 bignum > parsing. Minimum key length checks render this bug unexploitable to > compromise SSH 1 sessions. > > * sshd_config(5): clarify behaviour of a keyword that appears in > multiple matching Match blocks. bz#2184 > > * ssh(1): avoid unnecessary hostname lookups when canonicalisation is > disabled. bz#2205 > > * sshd(8): avoid sandbox violation crashes in GSSAPI code by caching > the supported list of GSSAPI mechanism OIDs before entering the > sandbox. bz#2107 > > * ssh(1): fix possible crashes in SOCKS4 parsing caused by assumption > that the SOCKS username is nul-terminated. > > * ssh(1): fix regression for UsePrivilegedPort=yes when BindAddress is > not specified. > > * ssh(1), sshd(8): fix memory leak in ECDSA signature verification. > > * ssh(1): fix matching of 'Host' directives in ssh_config(5) files > to be case-sensitive again (regression in 6.5). > > Portable OpenSSH: > > * sshd(8): don't fatal if the FreeBSD Capsicum is offered by the > system headers and libc but is not supported by the kernel. > * Fix build using the HP-UX compiler. > > Reporting Bugs: > =============== > > - Please read http://www.openssh.com/report.html > Security bugs should be reported directly to openssh at openssh.com > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and > Ben Lindstrom. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From djm at mindrot.org Sat Mar 1 20:33:30 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 1 Mar 2014 20:33:30 +1100 (EST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: On Fri, 28 Feb 2014, Hisashi T Fujinaka wrote: > I'm not sure if I'm supposed to be testing yet, but since I'm the pesky > NetBSD guy, I did: > > git clone https://github.com/openssh/openssh-portable/ > > and after the autoreconf && ./configure && make tests, I got: > > run test dhgex.sh ... > dhgex bits 3072 diffie-hellman-group-exchange-sha1 cast128-cbc > FATAL: dhgex expected 3072 bit group, got 2048 oh, I bet it is not finding /etc/moduli whereever it expects it and falling back to dh.c:dh_new_group14() Darren - I'm not sure this test will work correctly before installation and we have no sshd_config(5) ModuliFile option to work around this. Maybe we should disable it for release? Or make it "test -f /etc/moduli" first? -d From mancha1 at hush.com Sat Mar 1 20:54:00 2014 From: mancha1 at hush.com (mancha) Date: Sat, 01 Mar 2014 09:54:00 +0000 Subject: Call for testing: OpenSSH 6.6 Message-ID: <20140301095400.87B1920389@smtp.hushmail.com> On Fri, 28 Feb 2014 22:41:37 +0000 "Damien Miller" wrote: >Hi, > >OpenSSH 6.6 is almost ready for release, so we would appreciate >testing on as many platforms and systems as possible. This is a >small release mostly to fix some minor but annoying bugs in >openssh-6.5. >Running the regression tests supplied with Portable OpenSSH does >not require installation and is a simply: > >$ ./configure && make tests Hi. After configure && make tests, sshd defaults to looking for the system moduli file at /usr/local/etc/moduli. If it doesn't find it there, the fallback is using dh group-14 (2048-bit modulus). This is causing the the dhgex.sh test errors reported by Hisashi & Loganaden (i.e. 3072 != 2048). To resolve this on my system (where moduli file is at /etc/ssh /moduli), I use: $ ./configure && make tests sysconfdir=/etc/ssh Also, on the system I tested (Slackware Linux), the client logfile has CRLF line terminators so $gotbits contains a trailing ^M and the comparison fails. Patch below is one way to fix this: --- a/dhgex.sh +++ b/dhgex.sh @@ -29,7 +29,7 @@ ssh_test_dhgex() fail "$tid unexpected GEX sizes, expected $groupsz, got $got" fi # check what we got (depends on contents of system moduli file) - gotbits="`awk '/bits set:/{print $4}' ${LOG} | head -1 | cut -f2 -d/`" + gotbits="`awk '/bits set:/{print $4}' ${LOG} | head -1 | cut -f2 -d/ | sed -e 's/\r$//'`" if [ "$gotbits" -lt "$bits" ]; then fatal "$tid expected $bits bit group, got $gotbits" fi With these two changes, all tests pass on Slackware Linux 14.1. --mancha From kevin.brott at gmail.com Sat Mar 1 20:56:40 2014 From: kevin.brott at gmail.com (Kevin Brott) Date: Sat, 1 Mar 2014 01:56:40 -0800 Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: Same error during make test using openssh-SNAP-20140301.tar.gz on Debian GNU/Linux 7.4 (wheezy) x86_64-unknown-linux-gnu with gcc (Debian 4.7.2-5) OpenSSL 1.0.1e On Sat, Mar 1, 2014 at 1:33 AM, Damien Miller wrote: > On Fri, 28 Feb 2014, Hisashi T Fujinaka wrote: > > > I'm not sure if I'm supposed to be testing yet, but since I'm the pesky > > NetBSD guy, I did: > > > > git clone https://github.com/openssh/openssh-portable/ > > > > and after the autoreconf && ./configure && make tests, I got: > > > > run test dhgex.sh ... > > dhgex bits 3072 diffie-hellman-group-exchange-sha1 cast128-cbc > > FATAL: dhgex expected 3072 bit group, got 2048 > > oh, I bet it is not finding /etc/moduli whereever it expects it and > falling back to dh.c:dh_new_group14() > > Darren - I'm not sure this test will work correctly before installation > and we have no sshd_config(5) ModuliFile option to work around this. > Maybe we should disable it for release? Or make it "test -f /etc/moduli" > first? > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- # include /* Kevin Brott */ From kevin.brott at gmail.com Sat Mar 1 21:24:06 2014 From: kevin.brott at gmail.com (Kevin Brott) Date: Sat, 1 Mar 2014 02:24:06 -0800 Subject: Call for testing: OpenSSH 6.6 In-Reply-To: <20140301095400.87B1920389@smtp.hushmail.com> References: <20140301095400.87B1920389@smtp.hushmail.com> Message-ID: After manually tweaking the dhgex.sh file (gnupatch even un-wrapped still won't apply), and pointing the make test sysconfdir to the installed config directory on my Debian box - all tests do pass. But I'm not sure the config suite should assume there's already a working ssh config somewhere, and go looking for it (HP-UX uses a non-std location, so do our localize builds), as some baseline systems won't even have it. This bit works with gnupatch to fix dhgex.sh for the CR issue ... but fixing the CR issue in the test file might make more sense and avoid needing this. *** openssh/regress/dhgex.sh.orig Thu Feb 27 15:21:30 2014 --- openssh/regress/dhgex.sh Sat Mar 1 02:00:42 2014 *************** *** 32 **** ! gotbits="`awk '/bits set:/{print $4}' ${LOG} | head -1 | cut -f2 -d/`" --- 32 ---- ! gotbits="`awk '/bits set:/{print $4}' ${LOG} | head -1 | cut -f2 -d/ | sed -e 's/\r$//'`" On Sat, Mar 1, 2014 at 1:54 AM, mancha wrote: > On Fri, 28 Feb 2014 22:41:37 +0000 "Damien Miller" wrote: > >Hi, > > > >OpenSSH 6.6 is almost ready for release, so we would appreciate > >testing on as many platforms and systems as possible. This is a > >small release mostly to fix some minor but annoying bugs in > >openssh-6.5. > > >Running the regression tests supplied with Portable OpenSSH does > >not require installation and is a simply: > > > >$ ./configure && make tests > > Hi. > > After configure && make tests, sshd defaults to looking for the > system moduli file at /usr/local/etc/moduli. If it doesn't find > it there, the fallback is using dh group-14 (2048-bit modulus). > > This is causing the the dhgex.sh test errors reported by Hisashi > & Loganaden (i.e. 3072 != 2048). > > To resolve this on my system (where moduli file is at /etc/ssh > /moduli), I use: > > $ ./configure && make tests sysconfdir=/etc/ssh > > Also, on the system I tested (Slackware Linux), the client logfile > has CRLF line terminators so $gotbits contains a trailing ^M and > the comparison fails. Patch below is one way to fix this: > > --- a/dhgex.sh > +++ b/dhgex.sh > @@ -29,7 +29,7 @@ ssh_test_dhgex() > fail "$tid unexpected GEX sizes, expected $groupsz, > got $got" > fi > # check what we got (depends on contents of system moduli > file) > - gotbits="`awk '/bits set:/{print $4}' ${LOG} | head -1 | > cut -f2 -d/`" > + gotbits="`awk '/bits set:/{print $4}' ${LOG} | head -1 | > cut -f2 -d/ | sed -e 's/\r$//'`" > if [ "$gotbits" -lt "$bits" ]; then > fatal "$tid expected $bits bit group, got $gotbits" > fi > > With these two changes, all tests pass on Slackware Linux 14.1. > > --mancha > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- # include /* Kevin Brott */ From mancha1 at hush.com Sat Mar 1 21:54:41 2014 From: mancha1 at hush.com (mancha) Date: Sat, 01 Mar 2014 10:54:41 +0000 Subject: Call for testing: OpenSSH 6.6 Message-ID: <20140301105441.C08C620389@smtp.hushmail.com> On Sat, 01 Mar 2014 10:24:08 +0000 "Kevin Brott" wrote: >After manually tweaking the dhgex.sh file (gnupatch even un- >wrapped still won't apply) My email must have mangled whitespace because our patches do the same thing. >fixing the CR issue in the test file might make more sense >and avoid needing this. OpenSSH logfiles are CRLF terminated - it's not just when running the test suite. I don't think it's considered broken but intended. >and pointing the make test sysconfdir to the installed config >directory on my Debian box - all tests do pass. But I'm not sure >the config suite should assume there's already a working ssh >config somewhere, and go looking for it (HP-UX uses a non-std >location, so do our localize I agree. To use the staging dir's moduli file so it doesn't depend on having an installed system moduli file you can do: $ ./configure && make tests sysconfdir=$(pwd) This could be forced in the makefile's test target so it works automagically. --mancha From vinschen at redhat.com Sat Mar 1 23:06:46 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 1 Mar 2014 13:06:46 +0100 Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: <20140301120646.GG2381@calimero.vinschen.de> On Mar 1 09:19, Damien Miller wrote: > Hi, > > OpenSSH 6.6 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is a small release > mostly to fix some minor but annoying bugs in openssh-6.5. Builds OOTB on Cygwin, all tests pass. One questions though: > * ssh(1): fix matching of 'Host' directives in ssh_config(5) files > to be case-sensitive again (regression in 6.5). Shouldn't that be "case-*in*sensitive here? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From djm at mindrot.org Sun Mar 2 04:02:06 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 2 Mar 2014 04:02:06 +1100 (EST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: <20140301120646.GG2381@calimero.vinschen.de> References: <20140301120646.GG2381@calimero.vinschen.de> Message-ID: On Sat, 1 Mar 2014, Corinna Vinschen wrote: > > * ssh(1): fix matching of 'Host' directives in ssh_config(5) files > > to be case-sensitive again (regression in 6.5). > > Shouldn't that be "case-*in*sensitive here? Yep - that's a typo From djm at mindrot.org Sun Mar 2 04:03:43 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 2 Mar 2014 04:03:43 +1100 (EST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: On Sat, 1 Mar 2014, Damien Miller wrote: > Darren - I'm not sure this test will work correctly before installation > and we have no sshd_config(5) ModuliFile option to work around this. > Maybe we should disable it for release? Or make it "test -f /etc/moduli" > first? For now I've commented out the dhgex.sh test. openssh-SNAP-20140302.tar.gz has the test disabled. -d From mancha1 at hush.com Sun Mar 2 08:26:59 2014 From: mancha1 at hush.com (mancha) Date: Sat, 01 Mar 2014 21:26:59 +0000 Subject: FYI: Flush+Reload attack on OpenSSL's ECDSA Message-ID: <20140301212659.F1ED9608B1@smtp.hushmail.com> Here's a recently-published paper that describes a flush & reload attack on OpenSSL's ECDSA implementation: http://eprint.iacr.org/2014/140.pdf According to the authors, snooping a single signing round is sufficient to recover the secret key. --mancha From mikep at noc.utoronto.ca Sun Mar 2 09:24:44 2014 From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca) Date: Sat, 1 Mar 2014 17:24:44 -0500 (EST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: <20140301105441.C08C620389@smtp.hushmail.com> References: <20140301105441.C08C620389@smtp.hushmail.com> Message-ID: Built 'openssh-SNAP-20140301' on Solaris 10 with 'gcc'; no errors; 'ssh' as 'root' now works (failed with 6.5p1). 2 issues: In 'ssh_config', setting: KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 used to allow connections to Cisco routers to work, but now the connection attempt hangs. With the current version, any one of: KexAlgorithms diffie-hellman-group-exchange-sha1 KexAlgorithms diffie-hellman-group14-sha1 KexAlgorithms diffie-hellman-group1-sha1 KexAlgorithms diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 works, but this hangs: KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 On Sat, 1 Mar 2014, mancha wrote: > $ ./configure && make tests sysconfdir=$(pwd) > > This could be forced in the makefile's test target so it works > automagically. 'make tests', 'make tests sysconfdir=$PWD' and 'make tests sysconfdir=/etc/ssh' all fail with: ... sftp permissions: read-only upload sftp permissions: read-only setstat postcondition check failed: setstat readonly sftp permissions: read-only rm sftp permissions: read-only mkdir sftp permissions: read-only rmdir sftp permissions: read-only posix-rename sftp permissions: read-only oldrename sftp permissions: read-only symlink sftp permissions: read-only hardlink sftp permissions: explicit open sftp permissions: explicit read sftp permissions: explicit write sftp permissions: explicit lstat sftp permissions: explicit opendir sftp permissions: explicit readdir sftp permissions: explicit setstat postcondition check failed: setstat blacklisted postcondition check failed: setstat not in whitelist sftp permissions: explicit remove sftp permissions: explicit mkdir sftp permissions: explicit rmdir sftp permissions: explicit posix-rename sftp permissions: explicit rename sftp permissions: explicit symlink sftp permissions: explicit hardlink sftp permissions: explicit statvfs failed sftp permissions make[1]: *** [t-exec] Error 1 with lots of 'Unsupported query "cipher-auth"' messages before that point. Mike -- Mike Peterson Information Security Analyst - Audit E-mail: mikep at noc.utoronto.ca WWW: http://www.noc.utoronto.ca/ Tel: 416-978-5230 Fax: 416-978-6620 From mancha1 at hush.com Sun Mar 2 10:19:50 2014 From: mancha1 at hush.com (mancha) Date: Sat, 01 Mar 2014 23:19:50 +0000 Subject: Call for testing: OpenSSH 6.6 Message-ID: <20140301231950.98059608B0@smtp.hushmail.com> On Sat, 01 Mar 2014 22:24:46 +0000 mikep at noc.utoronto.ca wrote: >Built 'openssh-SNAP-20140301' on Solaris 10 with 'gcc'; no errors; >'ssh' as 'root' now works (failed with 6.5p1). > >2 issues: > >In 'ssh_config', setting: > > KexAlgorithms diffie-hellman-group-exchange-sha256,diffie- >hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie- >hellman-group1-sha1 > >used to allow connections to Cisco routers to work, but now the >connection >attempt hangs. With the current version, any one of: > > KexAlgorithms diffie-hellman-group-exchange-sha1 > KexAlgorithms diffie-hellman-group14-sha1 > KexAlgorithms diffie-hellman-group1-sha1 > KexAlgorithms diffie-hellman-group14-sha1,diffie-hellman- >group1-sha1 > >works, but this hangs: > > KexAlgorithms diffie-hellman-group-exchange-sha1,diffie- >hellman-group14-sha1,diffie-hellman-group1-sha1 As of OpenSSH 6.5, the size of the requested DH group (in DH GEX) increased at every security level (per NIST SP 800-57). My guess is Cisco's sshd implementation is RFC4419 non-compliant. If this is the case, there's a *very* long thread on the ML which discusses the DG GEX change. Search for "3des cipher and DH group size" >On Sat, 1 Mar 2014, mancha wrote: > >> $ ./configure && make tests sysconfdir=$(pwd) >> >> This could be forced in the makefile's test target so it works >> automagically. > >'make tests', 'make tests sysconfdir=$PWD' and 'make tests >sysconfdir=/etc/ssh' all fail with: > Setting sysconfdir was a work-around for the dhgex.sh test. openssh-SNAP-20140302+ disables that test. --mancha From htodd at twofifty.com Sun Mar 2 11:10:51 2014 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Sat, 1 Mar 2014 16:10:51 -0800 (PST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: OK, if I comment that out it all works on NetBSD and Mavericks! On Sun, 2 Mar 2014, Damien Miller wrote: > On Sat, 1 Mar 2014, Damien Miller wrote: > >> Darren - I'm not sure this test will work correctly before installation >> and we have no sshd_config(5) ModuliFile option to work around this. >> Maybe we should disable it for release? Or make it "test -f /etc/moduli" >> first? > > For now I've commented out the dhgex.sh test. openssh-SNAP-20140302.tar.gz > has the test disabled. > > -d > -- Hisashi T Fujinaka - htodd at twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte From andyb1 at andy-t.org Sun Mar 2 15:09:12 2014 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Sat, 1 Mar 2014 22:09:12 -0600 (CST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: openssh-SNAP-20140302.tar.gz builds and passes all tests on Slackware-14.0 and 13.37, both 64-bit. There is, however, a problem with scp which I reported earlier, Jan 20, during 6.5 testing, and which did not get any reply. So I re-tested it, and it is still there. Since the problem is with scp which relies on installed ssh, I built a Slackware-13.37 openssh package, and installed it in a VM. The problem happens when I run `scp -3' and only when both remote accounts require passwords. Second password is echo'ed to the terminal. Below is a full session showing what happens: --------------------------------------------- scp -3 andyt2 at majesty:/etc/group andyt2 at mate:/tmp/group andyt2 at majesty's password: andyt2 at mate's password: XXXXXX --------------------------- As you can see, after the command is started, both remote systems prompt for a password on the same line. So I enter a password for user andyt2 and press ENTER. What happens next is probably a bug. Line advances, and nothing at all happens. So I am assuming that now the second system is waiting for a password. I enter it, and it appears in the terminal in cleartext (substituted here with XXXXXX). The command then proceeds and finishes successfully. A workaround I found is to simply press ENTER instead of typing a second password. Then, you get an error saying the password is incorrect, and a new, normal password prompt appears. Enter the password, and this time, it is not visible. This is what it looks like: ---------------------------- andyt at king: andyt> scp -3 andyt2 at majesty:/etc/group andyt2 at mate:/tmp/group andyt2 at majesty's password: andyt2 at mate's password: Permission denied, please try again. andyt2 at mate's password: ---------------------------- I would think scp should try to connect to the first remote machine, and only when/if authentication completes successfully proceed with the second remote machine. Regards, Andy On Sat, 1 Mar 2014, Damien Miller wrote: > Hi, > > OpenSSH 6.6 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is a small release > mostly to fix some minor but annoying bugs in openssh-6.5. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Git at https://anongit.mindrot.org/openssh.git/ > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the ChangeLog > in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > Changes since OpenSSH 6.5 > ========================= > > This is primarily a bugfix release. > > New / changed features: > > * ssh(1), sshd(8): this release removes the J-PAKE authentication code. > This code was experimental, never enabled and had been unmaintained > for some time. > > * ssh(1): when processing Match blocks, skip 'exec' clauses other clauses > predicates failed to match. > > * ssh(1): if hostname canonicalisation is enabled and results in the > destination hostname being changed, then re-parse ssh_config(5) files > using the new destination hostname. This gives 'Host' and 'Match' > directives that use the expanded hostname a chance to be applied. > > Bugfixes: > > * ssh(1): avoid spurious "getsockname failed: Bad file descriptor" in > ssh -W. bz#2200, debian#738692 > > * sshd(8): allow the shutdown(2) syscall in seccomp-bpf and systrace > sandbox modes, as it is reachable if the connection is terminated > during the pre-auth phase. > > * ssh(1), sshd(8): fix unsigned overflow that in SSH protocol 1 bignum > parsing. Minimum key length checks render this bug unexploitable to > compromise SSH 1 sessions. > > * sshd_config(5): clarify behaviour of a keyword that appears in > multiple matching Match blocks. bz#2184 > > * ssh(1): avoid unnecessary hostname lookups when canonicalisation is > disabled. bz#2205 > > * sshd(8): avoid sandbox violation crashes in GSSAPI code by caching > the supported list of GSSAPI mechanism OIDs before entering the > sandbox. bz#2107 > > * ssh(1): fix possible crashes in SOCKS4 parsing caused by assumption > that the SOCKS username is nul-terminated. > > * ssh(1): fix regression for UsePrivilegedPort=yes when BindAddress is > not specified. > > * ssh(1), sshd(8): fix memory leak in ECDSA signature verification. > > * ssh(1): fix matching of 'Host' directives in ssh_config(5) files > to be case-sensitive again (regression in 6.5). > > Portable OpenSSH: > > * sshd(8): don't fatal if the FreeBSD Capsicum is offered by the > system headers and libc but is not supported by the kernel. > * Fix build using the HP-UX compiler. > > Reporting Bugs: > =============== > > - Please read http://www.openssh.com/report.html > Security bugs should be reported directly to openssh at openssh.com > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and > Ben Lindstrom. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Dr Andy Tsouladze Sr Unix/Storage/Security SysAdmin PWD=`cat /dev/urandom | sed 's/[^\x21-\x7f]//g' | head -c 14` From djm at mindrot.org Sun Mar 2 20:59:12 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 2 Mar 2014 20:59:12 +1100 (EST) Subject: FYI: Flush+Reload attack on OpenSSL's ECDSA In-Reply-To: <20140301212659.F1ED9608B1@smtp.hushmail.com> References: <20140301212659.F1ED9608B1@smtp.hushmail.com> Message-ID: On Sat, 1 Mar 2014, mancha wrote: > Here's a recently-published paper that describes a flush & reload > attack on OpenSSL's ECDSA implementation: > > http://eprint.iacr.org/2014/140.pdf > > According to the authors, snooping a single signing round is > sufficient to recover the secret key. It sounds like an interesting technique, though I note that they attacked signing using one of the GF(2^m) curves rather than the GP(p) curves that almost everything uses. Why? -d From mancha1 at hush.com Mon Mar 3 05:47:05 2014 From: mancha1 at hush.com (mancha) Date: Sun, 2 Mar 2014 18:47:05 +0000 (UTC) Subject: FYI: Flush+Reload attack on OpenSSL's ECDSA References: <20140301212659.F1ED9608B1@smtp.hushmail.com> Message-ID: Damien Miller mindrot.org> writes: > > On Sat, 1 Mar 2014, mancha wrote: > > > Here's a recently-published paper that describes a flush & reload > > attack on OpenSSL's ECDSA implementation: > > > > http://eprint.iacr.org/2014/140.pdf > > > > According to the authors, snooping a single signing round is > > sufficient to recover the secret key. > > It sounds like an interesting technique, though I note that they > attacked signing using one of the GF(2^m) curves rather than the > GP(p) curves that almost everything uses. Why? > > -d > The OpenSSL branching conditions targeted by this particular flush+reload attack are part of an optimized algorithm, thanks to Lopez/Dahab 1999, for computing elliptic scalar multiplication on curves defined over binary fields GF(2^m). Brumley/Hakala 2009, on the other hand, outline a cache-timing attack on OpenSSL's algorithm for computing elliptic scalar multiplication on curves defined over prime fields GF(p). --mancha From carsten at wieschiolek.de Mon Mar 3 22:09:58 2014 From: carsten at wieschiolek.de (Carsten Wieschiolek) Date: Mon, 03 Mar 2014 12:09:58 +0100 Subject: Bug: Environment vars are changed before use (locale LANG, LC_*) In-Reply-To: References: <530CC263.1000106@wieschiolek.de> Message-ID: <53146306.4070408@wieschiolek.de> Hi Damien! Thanks for the friendly reply! I did a few more tests to investigate the matter further based on your comments. The bottom line is, that the settings from the file "environment" in the .ssh directory are not considered at all. The values from the calling SHELL have precedence over the entries in the file, which makes the file quite useless. Am I overlooking something important? Best Regards Carsten Wieschiolek Am 28.02.2014 23:19, schrieb Damien Miller: > On Tue, 25 Feb 2014, Carsten Wieschiolek wrote: > >> Hi >> >> I am using >> >> OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013 >> >> on a Ubuntu 13.10 release for access to various kinds of systems. This >> recent Ubuntu OS insists on standard conforming locales, i.e. >> de_DE.UTF-8 instead of de_DE.utf8 as in the previous release. When I am >> using SSH to communicate with another system not being able to process >> the standard conformant setting (in my case HP-UX B.11.31), problems >> arise, because the new setting cannot be processed. Even when I am >> specifying the variable in the environment file of SSH in a form usable >> by the remote system, they are changed into the standard conformant >> setting first, before being transferred. This is a bug, because these >> environment variables are intended to be processed on the remote system >> as given in the local file. SSH should keep the values in the original >> format specified and rely on translation by the remote system. It is >> pointless to use setlocale(3) locally. > OpenSSH doesn't perform any transformation of environment variables > that are forwarded. Some possibilities: > > * your vendor included a patch to transform these environment variables > * the enviornment variables are being overridden by PAM (see > https://bugzilla.mindrot.org/show_bug.cgi?id=1346 ) > * they are being overridden by a shell initialisation file (e.g. > .bash_profile) > > -d > From djm at mindrot.org Tue Mar 4 04:53:54 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 4 Mar 2014 04:53:54 +1100 (EST) Subject: Bug: Environment vars are changed before use (locale LANG, LC_*) In-Reply-To: <53146306.4070408@wieschiolek.de> References: <530CC263.1000106@wieschiolek.de> <53146306.4070408@wieschiolek.de> Message-ID: On Mon, 3 Mar 2014, Carsten Wieschiolek wrote: > Hi Damien! > > Thanks for the friendly reply! > > I did a few more tests to investigate the matter further based on > your comments. The bottom line is, that the settings from the file > "environment" in the .ssh directory are not considered at all. The > values from the calling SHELL have precedence over the entries in the > file, which makes the file quite useless. Am I overlooking something > important? The order is something like: 1. Environment variables passed by SendEnv/AcceptEnv 2. Environment variables specified by pam_env 3. ~/.ssh/enviornment 4. Environment variables set by the shell (I might have #2 and #3 reversed here) #1, #2 and #3 all prepare the environment that the shell is executed with, so naturally anything the shell does will overrride them. As for how to fix it. One way is to rename the environment variables and then have your shell initialisation put them back. E.g. preferred_LANG=en_AU:en in ~/.ssh/enviornment, and test -z "$preferred_LANG" && LANG="$preferred_LANG" export LANG in your shell initialisation. -d From mancha1 at hush.com Tue Mar 4 06:51:09 2014 From: mancha1 at hush.com (mancha) Date: Mon, 3 Mar 2014 19:51:09 +0000 (UTC) Subject: FYI: Flush+Reload attack on OpenSSL's ECDSA References: <20140301212659.F1ED9608B1@smtp.hushmail.com> Message-ID: mancha hush.com> writes: > > Damien Miller mindrot.org> writes: > > [SNIP QUOTED] > > It sounds like an interesting technique, though I note that they > > attacked signing using one of the GF(2^m) curves rather than the > > GP(p) curves that almost everything uses. Why? > > > > -d > > > > The OpenSSL branching conditions targeted by this particular > flush+reload attack are part of an optimized algorithm, thanks > to Lopez/Dahab 1999, for computing elliptic scalar multiplication > on curves defined over binary fields GF(2^m). > > Brumley/Hakala 2009, on the other hand, outline a cache-timing > attack on OpenSSL's algorithm for computing elliptic scalar > multiplication on curves defined over prime fields GF(p). > > --mancha > Brumley, Hakala, "Cache-Timing Template Attacks" (2009) http://www.iacr.org/archive/asiacrypt2009/59120664/59120664.pdf Lopez, Dahab, "Fast Multiplication on Elliptic Curves over GF(2^m) without Precomputation" (1999) http://link.springer.com/content/pdf/10.1007/3-540-48059-5_27.pdf --mancha From pnayanag at cisco.com Tue Mar 4 19:39:01 2014 From: pnayanag at cisco.com (Prashanth Nayanagari -X (pnayanag - HCL TECHNOLOGIES LIMITED at Cisco)) Date: Tue, 4 Mar 2014 08:39:01 +0000 Subject: Issue With SSHD Password Guesses Message-ID: <51386C4C4B68B9488E99BAE58D8EF63F39984D86@xmb-aln-x03.cisco.com> Hi, Initially when we do ssh from Cisco IOS Router to my linux machine, we use to see only one password prompt , even though we configured number of password prompts in Linux machine to 3. So, to overcome this issue , someone changed the values in sshd_config file in openssh-3.5pl. Before Fix #ChallengeResponseAuthentication yes #PAMAuthenticationViaKbdInt no After Fix ChallengeResponseAuthentication no PAMAuthenticationViaKbdInt no So, after this when we do ssh from IOs Router, the number of password prompts got increased, means if we configure 1 in linux device, the number of password prompts for wrong password seen is 2. And if we configure 2, the number of password prompts for wrong password seen is 3. So, can you please help me , why the Linux machine is behaving like this. We are using openssh-3.5 and ssh version 2. Thanks in advance. With Regards, Prashanth N. From saku at ytti.fi Wed Mar 5 02:25:40 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 4 Mar 2014 17:25:40 +0200 Subject: Issue With SSHD Password Guesses In-Reply-To: <51386C4C4B68B9488E99BAE58D8EF63F39984D86@xmb-aln-x03.cisco.com> References: <51386C4C4B68B9488E99BAE58D8EF63F39984D86@xmb-aln-x03.cisco.com> Message-ID: <20140304152540.GA14520@pob.ytti.fi> On (2014-03-04 08:39 +0000), Prashanth Nayanagari -X (pnayanag - HCL TECHNOLOGIES LIMITED at Cisco) wrote: Hi Prashanth, > So, can you please help me , why the Linux machine is behaving like this. > We are using openssh-3.5 and ssh version 2. I'm sorry to hijack you like this, but I've tried previously via proper channels and it will not be fixed, as it's not a bug. In classic IOS when channel closes your transport connection closes. That is, you cannot open exec('command1'), exec('command2') to gather output of two commands, the moment first one closes, TCP terminates. I don't know if standard allows this or not, but to me it seems like bug. Because that does not work, you're forced to open shell and do problematic screen-scraping to determine when each command starts and stops. Thank you and sorry, -- ++ytti From imorgan at nas.nasa.gov Wed Mar 5 06:46:43 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 4 Mar 2014 11:46:43 -0800 Subject: Issue With SSHD Password Guesses In-Reply-To: <51386C4C4B68B9488E99BAE58D8EF63F39984D86@xmb-aln-x03.cisco.com> References: <51386C4C4B68B9488E99BAE58D8EF63F39984D86@xmb-aln-x03.cisco.com> Message-ID: <20140304194643.GA6663@linux124.nas.nasa.gov> On Tue, Mar 04, 2014 at 08:39:01 +0000, Prashanth Nayanagari -X (pnayanag - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Hi, > > Initially when we do ssh from Cisco IOS Router to my linux machine, we use to see only one password prompt , even though we configured number of password prompts in Linux machine to 3. For OpenSSH, the server does not specifically constrain the number of pasword authentication attempts. MaxAuthTries (default is 6) is the maximum number of authentication attempts (of any sort) per connection. Normally, the number of password prompts is configured by on the client, not the server. So, how did you attempt to do this? Or, do you really mean that you were connecting from the Linux box to the Cisco router? > So, to overcome this issue , someone changed the values in sshd_config file in openssh-3.5pl. Wow, OpenSSH 3.5p1 is __ancient__! It dates form October, 2002; a _lot_ has changed since then. > Before Fix > > #ChallengeResponseAuthentication yes > #PAMAuthenticationViaKbdInt no > > After Fix > > ChallengeResponseAuthentication no > PAMAuthenticationViaKbdInt no > > So, after this when we do ssh from IOs Router, the number of password prompts got increased, means if we configure 1 in linux device, the number of password prompts for wrong password seen is 2. And if we configure 2, the number of password prompts for wrong password seen is 3. > > So, can you please help me , why the Linux machine is behaving like this. > We are using openssh-3.5 and ssh version 2. > > Thanks in advance. > To make sure that I am understanding you correctly, initially you were getting just one password prompt, but after editing the sshd_config you get one more prompt than you expected. Is that correct? Are all the prompts identical? It would help to see a sample of how you are geing prompted. Also, what precisely was changed to try to adjust the number of password prompts on the server side. Finally, I feel compelled to recommend that you upgrade OpenSSH to a more recent version. Aside from the various security enhancements and bug fixes that have been incorporated over the past decade, it would be much easire to give useful advise for a version that those on the list have more recent experience with. -- Iain Morgan From sangeeth.saravanaraj at gmail.com Thu Mar 6 05:46:18 2014 From: sangeeth.saravanaraj at gmail.com (Sangeeth Saravanaraj) Date: Thu, 6 Mar 2014 00:16:18 +0530 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 Message-ID: I want to configure secure shell access to a Linux machine where allowed users are stored in an sqlite3 database and not in the /etc/passwd, /etc/shadow and /etc/group. I use PAM for user authentication. In this case I use libpam_sqlitewhich performs PAM actions like auth, account, password, etc on user data stored in an sqlite3 database. I have the following configuration in my /etc/pam.d/sshd auth required /lib/security/pam_sqlite3.so account required /lib/security/pam_sqlite3.so password required /lib/security/pam_sqlite3.so When I tried to ssh to the box using a userid which is residing in the sqlite3 database only (and not in /etc/passwd), the authentication failed. The problem I found was, when an ssh is attempted, OpenSSH module is trying to get the user info from the /etc/passwd file and when it found that the user does not exist, it passes "#010#012#015#177INCORRECT" as the password (and discards the password entered by the user) to the libpam_sqlite module. Then obviously the libpam_sqlite3 denies access to the user because the password is incorrect! When looked into the OpenSSH code, I found that getpwnam() in auth.c::getpwnamallow() sets pw = NULL and so the following message appears! debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0 Invalid user XXXXXX from A.B.C.D Now, to the questions: 1. Why does OpenSSH replaces the password entered by the user with the bad password - "\b\n\r\177INCORRECT" when the user is not present in the /etc/passwd file? 2. Is there a way to tell OpenSSH not to override the password entered by the user? 3. Is it really possible to authenticate a user based on an sqlite3 database when the user record is not present in the /etc/passwd, /etc/shadow and /etc/group? Thank you, Sangeeth From kop at meme.com Thu Mar 6 06:00:41 2014 From: kop at meme.com (Karl O. Pinc) Date: Wed, 05 Mar 2014 13:00:41 -0600 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 In-Reply-To: (from sangeeth.saravanaraj@gmail.com on Wed Mar 5 12:46:18 2014) References: Message-ID: <1394046041.3901.6@slate> On 03/05/2014 12:46:18 PM, Sangeeth Saravanaraj wrote: > I want to configure secure shell access to a Linux machine where > allowed > users are stored in an sqlite3 database and not in the /etc/passwd, > /etc/shadow and /etc/group. I use PAM for user authentication. I can't speak to the internals but have you set UsePAM Yes in sshd_config? Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From sangeeth.saravanaraj at gmail.com Thu Mar 6 06:02:03 2014 From: sangeeth.saravanaraj at gmail.com (Sangeeth Saravanaraj) Date: Thu, 6 Mar 2014 00:32:03 +0530 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 In-Reply-To: <1394046041.3901.6@slate> References: <1394046041.3901.6@slate> Message-ID: On Thu, Mar 6, 2014 at 12:30 AM, Karl O. Pinc wrote: > On 03/05/2014 12:46:18 PM, Sangeeth Saravanaraj wrote: > > I want to configure secure shell access to a Linux machine where > > allowed > > users are stored in an sqlite3 database and not in the /etc/passwd, > > /etc/shadow and /etc/group. I use PAM for user authentication. > > I can't speak to the internals but have you set > UsePAM Yes in sshd_config? > Of course, Yes! > > > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > From Seth.Ellsworth at software.dell.com Thu Mar 6 06:06:42 2014 From: Seth.Ellsworth at software.dell.com (Seth Ellsworth) Date: Wed, 5 Mar 2014 19:06:42 +0000 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 In-Reply-To: <1394046041.3901.6@slate> References: <1394046041.3901.6@slate> Message-ID: <6E5C51EDC269B6438415FDE3E8A940EB12B7D3D5@ALVMBXW01.prod.quest.corp> A user consists of two parts: Identity and Authentication. /etc/passwd is Identity. The user's uid, home directory, etc. /etc/shadow is Authentication. Their password (hashed). PAM is Pluggable Authentication Module. It only handles Authentication. The user still has to have an Identity at the NSS layer. ( NSS == Name Service Switch ) ssh -> nss -> nsswitch.conf -> sqlite3 Is there an nss module also configured for sqlite3? Seth Ellsworth -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+seth.ellsworth=quest.com at mindrot.org] On Behalf Of Karl O. Pinc Sent: Wednesday, March 05, 2014 12:01 PM To: Sangeeth Saravanaraj Cc: openssh-unix-dev at mindrot.org Subject: Re: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 On 03/05/2014 12:46:18 PM, Sangeeth Saravanaraj wrote: > I want to configure secure shell access to a Linux machine where > allowed > users are stored in an sqlite3 database and not in the /etc/passwd, > /etc/shadow and /etc/group. I use PAM for user authentication. I can't speak to the internals but have you set UsePAM Yes in sshd_config? Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Tim.Broberg at servicenow.com Thu Mar 6 07:12:20 2014 From: Tim.Broberg at servicenow.com (Tim Broberg) Date: Wed, 5 Mar 2014 20:12:20 +0000 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 In-Reply-To: <6E5C51EDC269B6438415FDE3E8A940EB12B7D3D5@ALVMBXW01.prod.quest.corp> Message-ID: I hope you can forgive the meta-comment, but that might just be the highest signal to noise ratio post I've ever seen. (Perhaps some noise was needed to restore balance.) - Tim. On 3/5/14 11:06 AM, "Seth Ellsworth" wrote: >A user consists of two parts: Identity and Authentication. > >/etc/passwd is Identity. The user's uid, home directory, etc. >/etc/shadow is Authentication. Their password (hashed). > >PAM is Pluggable Authentication Module. >It only handles Authentication. > >The user still has to have an Identity at the NSS layer. >( NSS == Name Service Switch ) > >ssh -> nss -> nsswitch.conf -> sqlite3 >Is there an nss module also configured for sqlite3? > >Seth Ellsworth > > >-----Original Message----- >From: openssh-unix-dev >[mailto:openssh-unix-dev-bounces+seth.ellsworth=quest.com at mindrot.org] On >Behalf Of Karl O. Pinc >Sent: Wednesday, March 05, 2014 12:01 PM >To: Sangeeth Saravanaraj >Cc: openssh-unix-dev at mindrot.org >Subject: Re: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> >libpam_sqlite -> sqlite3 > >On 03/05/2014 12:46:18 PM, Sangeeth Saravanaraj wrote: >> I want to configure secure shell access to a Linux machine where >> allowed >> users are stored in an sqlite3 database and not in the /etc/passwd, >> /etc/shadow and /etc/group. I use PAM for user authentication. > >I can't speak to the internals but have you set >UsePAM Yes in sshd_config? > > > >Karl >Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://urldefense.proofpoint.com/v1/url?u=https://lists.mindrot.org/mailm >an/listinfo/openssh-unix-dev&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVY >S%2Bpq34MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=M1WP76oXGkI7kzNW5UjSw%2F4 >QZun2FxJY%2Bj2i3v%2FT8Tg%3D%0A&s=102c58d0c12ab23c4995a64e386bceb49dd6dabfb >7dcee662f0fd8f189e03685 >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://urldefense.proofpoint.com/v1/url?u=https://lists.mindrot.org/mailm >an/listinfo/openssh-unix-dev&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVY >S%2Bpq34MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=M1WP76oXGkI7kzNW5UjSw%2F4 >QZun2FxJY%2Bj2i3v%2FT8Tg%3D%0A&s=102c58d0c12ab23c4995a64e386bceb49dd6dabfb >7dcee662f0fd8f189e03685 From sangeeth.saravanaraj at gmail.com Thu Mar 6 09:01:25 2014 From: sangeeth.saravanaraj at gmail.com (Sangeeth Saravanaraj) Date: Thu, 6 Mar 2014 03:31:25 +0530 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 In-Reply-To: <6E5C51EDC269B6438415FDE3E8A940EB12B7D3D5@ALVMBXW01.prod.quest.corp> References: <1394046041.3901.6@slate> <6E5C51EDC269B6438415FDE3E8A940EB12B7D3D5@ALVMBXW01.prod.quest.corp> Message-ID: On Thu, Mar 6, 2014 at 12:36 AM, Seth Ellsworth < Seth.Ellsworth at software.dell.com> wrote: > A user consists of two parts: Identity and Authentication. > > /etc/passwd is Identity. The user's uid, home directory, etc. > /etc/shadow is Authentication. Their password (hashed). > > PAM is Pluggable Authentication Module. > It only handles Authentication. > > The user still has to have an Identity at the NSS layer. > ( NSS == Name Service Switch ) > > ssh -> nss -> nsswitch.conf -> sqlite3 > Is there an nss module also configured for sqlite3? > Hi Seth, Thanks for your comments! It really helped. I configured libnss-sqlite module to work with the sqlite3 database which contains user information. Also, I updated passwd, shadow and group config in /etc/nsswitch.conf to work with sqlite. With this setting, I was able to ssh to the Linux machine where all user information is stored in an Sqlite3 database. Thank you, Sangeeth > > Seth Ellsworth > > > -----Original Message----- > From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+seth.ellsworth= > quest.com at mindrot.org] On Behalf Of Karl O. Pinc > Sent: Wednesday, March 05, 2014 12:01 PM > To: Sangeeth Saravanaraj > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> > libpam_sqlite -> sqlite3 > > On 03/05/2014 12:46:18 PM, Sangeeth Saravanaraj wrote: > > I want to configure secure shell access to a Linux machine where > > allowed > > users are stored in an sqlite3 database and not in the /etc/passwd, > > /etc/shadow and /etc/group. I use PAM for user authentication. > > I can't speak to the internals but have you set > UsePAM Yes in sshd_config? > > > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From keisial at gmail.com Thu Mar 6 09:28:51 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 05 Mar 2014 23:28:51 +0100 Subject: Bad Password - #010#012#015#177INCORRECT : ssh -> pam -> libpam_sqlite -> sqlite3 In-Reply-To: References: <1394046041.3901.6@slate> <6E5C51EDC269B6438415FDE3E8A940EB12B7D3D5@ALVMBXW01.prod.quest.corp> Message-ID: <5317A523.1050805@gmail.com> For future archive searchers: > Why does OpenSSH replaces the password entered by the user with the > bad password - "\b\n\r\177INCORRECT There are some situations where sshd determines a user can't log in. Typical samples of that are DenyUsers or PermitRootLogin. In those cases sshd *still* calls PAM, so that delays set by it are still performed to the user (without leaking info about accounts existing, disabled, etc.). But in order to ensure it can't succeed, replaces the password with that impossible one. From lists at spuddy.org Fri Mar 7 02:02:46 2014 From: lists at spuddy.org (Stephen Harris) Date: Thu, 6 Mar 2014 10:02:46 -0500 Subject: Encryption Message-ID: <20140306150246.GA27803@mercury.spuddy.org> Am I correct in assuming that the user and host public/private keys used in openSSH are only used for authentication (is the remote server known to be X, is this Harry trying to login), and have no role in the encryption? I was under the assumption that each connection used a newly generated key (using DH for key exchange) so each session was unique. (I believe this because the transport layer needs to be set up before user keys are even presented, and rfc4253 #6.3 doesn't mention the host key). I'm being asked to provide private keys to allow network sniffing (problem analysis) but I'm not sure this is the right thing to do because I'm not convinced these keys are used as part of the encryption! Thanks... -- rgds Stephen From tomas.kuthan at oracle.com Fri Mar 7 02:58:01 2014 From: tomas.kuthan at oracle.com (Tomas Kuthan) Date: Thu, 06 Mar 2014 16:58:01 +0100 Subject: Encryption In-Reply-To: <20140306150246.GA27803@mercury.spuddy.org> References: <20140306150246.GA27803@mercury.spuddy.org> Message-ID: <53189B09.90103@oracle.com> On 03/ 6/14 04:02 PM, Stephen Harris wrote: > Am I correct in assuming that the user and host public/private keys used > in openSSH are only used for authentication (is the remote server known to > be X, is this Harry trying to login), and have no role in the encryption? > > I was under the assumption that each connection used a newly generated > key (using DH for key exchange) so each session was unique. > > (I believe this because the transport layer needs to be set up before > user keys are even presented, and rfc4253 #6.3 doesn't mention the host > key). > > I'm being asked to provide private keys to allow network sniffing > (problem analysis) but I'm not sure this is the right thing to do > because I'm not convinced these keys are used as part of the encryption! > > Thanks... > Hi Stephen, your understanding is correct. In DH key exchange, server's private key is used by the server to create a signature of exchange hash and the public key is used by the client to verify this signature. To eavesdropper these keys have no value, because they are not able to deduce the session key, nor the exchange hash. Tomas From mancha1 at hush.com Fri Mar 7 05:37:21 2014 From: mancha1 at hush.com (mancha) Date: Thu, 06 Mar 2014 18:37:21 +0000 Subject: [RFC] Add hash token to ControlPath Message-ID: <20140306183721.6EDA920106@smtp.hushmail.com> Hi. Last night on an irc openssh channel, a user brought up a use case involving cluster trees and very descriptive (i.e. long) hierarchical hostnames. To make a long story short, his ControlPath (~/.ssh/control-master /%r@%h:%p) was bumping up against UNIX_PATH_MAX. Attached patch adds a new percent-token (%H) that expands to the sha1 digest of the concatenation of host (%h) + port (%p) + remote user (%r). The token's expanded length is a fixed 40 characters and, barring digest collision, provides uniqueness. The patch was built against 6.5p1 but applies (with harmless offsets) to OpenBSD HEAD. --mancha From mancha1 at hush.com Fri Mar 7 06:00:55 2014 From: mancha1 at hush.com (mancha) Date: Thu, 6 Mar 2014 19:00:55 +0000 (UTC) Subject: [RFC] Add hash token to ControlPath References: <20140306183721.6EDA920106@smtp.hushmail.com> Message-ID: mancha hush.com> writes: > Attached patch adds a new percent-token (%H) that expands to the > sha1 digest of the concatenation of host (%h) + port (%p) + remote > user (%r). The token's expanded length is a fixed 40 characters > and, barring digest collision, provides uniqueness. > > The patch was built against 6.5p1 but applies (with harmless > offsets) to OpenBSD HEAD. > > --mancha Apologies but it seems the ML strips attachments. Rather than risk whitespace debacles with inline patches, I've placed it here: http://sf.net/projects/mancha/files/misc/openssh-6.5p1-mux-hash.diff From imorgan at nas.nasa.gov Fri Mar 7 06:13:01 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 6 Mar 2014 11:13:01 -0800 Subject: [RFC] Add hash token to ControlPath In-Reply-To: <20140306183721.6EDA920106@smtp.hushmail.com> References: <20140306183721.6EDA920106@smtp.hushmail.com> Message-ID: <20140306191301.GB6663@linux124.nas.nasa.gov> On Thu, Mar 06, 2014 at 18:37:21 +0000, mancha wrote: > Hi. > > Last night on an irc openssh channel, a user brought up a use > case involving cluster trees and very descriptive (i.e. long) > hierarchical hostnames. > > To make a long story short, his ControlPath (~/.ssh/control-master > /%r@%h:%p) was bumping up against UNIX_PATH_MAX. > > Attached patch adds a new percent-token (%H) that expands to the > sha1 digest of the concatenation of host (%h) + port (%p) + remote > user (%r). The token's expanded length is a fixed 40 characters > and, barring digest collision, provides uniqueness. > > The patch was built against 6.5p1 but applies (with harmless > offsets) to OpenBSD HEAD. > > --mancha I suppose the IP address of the destination host is not known at the time that the socket is created or initially accessed; but if it is, adding a macro for the IP address might be an alternative approach. With regard to your suggestion, it might also be worthwhile including the client hostname in the hash to cover scenarios where the sockets are created in shared filesystems. I'm also a little hesitant about using %H; in analogy to %l and %L, %H should be the first component of the destinations's name. Perhaps %M or %S? I'm not sure if the work being done to allow OpenSSH to be built without OpenSSL includes SHA-1 support. I assume that it does, but I haven't gottent around to looking at the code. If it doesn't, it might be necessary to use MD5 instead. -- Iain Morgan From mancha1 at hush.com Fri Mar 7 06:08:36 2014 From: mancha1 at hush.com (mancha) Date: Thu, 6 Mar 2014 19:08:36 +0000 (UTC) Subject: Encryption References: <20140306150246.GA27803@mercury.spuddy.org> <53189B09.90103@oracle.com> Message-ID: Tomas Kuthan oracle.com> writes: > > On 03/ 6/14 04:02 PM, Stephen Harris wrote: > > Am I correct in assuming that the user and host public/private keys used > > in openSSH are only used for authentication (is the remote server known to > > be X, is this Harry trying to login), and have no role in the encryption? > > > > I was under the assumption that each connection used a newly generated > > key (using DH for key exchange) so each session was unique. > > > > (I believe this because the transport layer needs to be set up before > > user keys are even presented, and rfc4253 #6.3 doesn't mention the host > > key). > > > > I'm being asked to provide private keys to allow network sniffing > > (problem analysis) but I'm not sure this is the right thing to do > > because I'm not convinced these keys are used as part of the encryption! > > > > Thanks... > > > > Hi Stephen, > > your understanding is correct. > In DH key exchange, server's private key is used by the server to create > a signature of exchange hash and the public key is used by the client to > verify this signature. > To eavesdropper these keys have no value, because they are not able to > deduce the session key, nor the exchange hash. > > Tomas > I am glad people are curious about the role things like host keys have (or don't have) in kexinit, transport, etc. Especially timely given recent (and not so recent) descriptions of side-channel attacks against algorithms such as OpenSSL ECDSA signing. A detailed flow diagram might speak a thousand words. Anyone have something like that handy? Note: these terms can get a little tricky but OpenSSH distinguishes between "host" keys and ephemeral "server" keys used in SSH1 mode. Excuse the pedantry. --mancha From scott_n at xypro.com Fri Mar 7 06:39:33 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 6 Mar 2014 19:39:33 +0000 Subject: Without OpenSSL? Message-ID: Quoth Iain: >I'm not sure if the work being done to allow OpenSSH to be built without OpenSSL includes SHA-1 support. Hi Iain. I haven't heard of this effort before. Can you give a few more details? Thanks, ScottN --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | From daniel.cegielka at gmail.com Fri Mar 7 06:52:32 2014 From: daniel.cegielka at gmail.com (=?ISO-8859-2?Q?Daniel_Cegie=B3ka?=) Date: Thu, 6 Mar 2014 20:52:32 +0100 Subject: Without OpenSSL? In-Reply-To: References: Message-ID: 2014-03-06 20:39 GMT+01:00 Scott Neugroschl : > Quoth Iain: >>I'm not sure if the work being done to allow OpenSSH to be built without OpenSSL includes SHA-1 support. > > Hi Iain. I haven't heard of this effort before. Can you give a few more details? > > Thanks, > > ScottN Hi, eg. revision 1.23: "avoid use of OpenSSL BIGNUM type and functions for KEX with Curve25519 by adding a buffer_put_bignum2_from_string() that stores a string using the bignum encoding rules. Will make it easier to build a reduced-feature OpenSSH without OpenSSL in the future; ok markus@" http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/buffer.h I hope that it will be possible to build a small version of sshd without OpenSSL. Any news on this topic are welcome. Daniel > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From imorgan at nas.nasa.gov Fri Mar 7 07:00:23 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 6 Mar 2014 12:00:23 -0800 Subject: Without OpenSSL? In-Reply-To: References: Message-ID: <20140306200023.GC6663@linux124.nas.nasa.gov> On Thu, Mar 06, 2014 at 19:39:33 +0000, Scott Neugroschl wrote: > Quoth Iain: > >I'm not sure if the work being done to allow OpenSSH to be built without OpenSSL includes SHA-1 support. > > Hi Iain. I haven't heard of this effort before. Can you give a few more details? > > Thanks, > > ScottN > Well, I'm not in a position to give any authoritative information, but here is what I know: With the addition of curve25519, ed25519, and chacha20+poly1305, the developers have commented about the possibility of building an RFC non-compliant OpenSSH without OpenSSL. If you search through the mailing list archive, I believe you chould see some references to this. There are also commtnes in the CVS commits regarding this. And, I believe Damien mentioned about this in his interview on bsdnow.tv. In one of the CVS commits, I noticed that there is support for falling back on libc for digest support when building without OpenSSL, but I don't recall if this is both MD5 and SHA1 or not. -- Iain Morgan From daniel.cegielka at gmail.com Fri Mar 7 07:32:35 2014 From: daniel.cegielka at gmail.com (=?ISO-8859-2?Q?Daniel_Cegie=B3ka?=) Date: Thu, 6 Mar 2014 21:32:35 +0100 Subject: Without OpenSSL? In-Reply-To: <20140306200023.GC6663@linux124.nas.nasa.gov> References: <20140306200023.GC6663@linux124.nas.nasa.gov> Message-ID: 2014-03-06 21:00 GMT+01:00 Iain Morgan : > On Thu, Mar 06, 2014 at 19:39:33 +0000, Scott Neugroschl wrote: >> Quoth Iain: >> >I'm not sure if the work being done to allow OpenSSH to be built without OpenSSL includes SHA-1 support. >> >> Hi Iain. I haven't heard of this effort before. Can you give a few more details? >> >> Thanks, >> >> ScottN >> > > Well, I'm not in a position to give any authoritative information, but > here is what I know: With the addition of curve25519, ed25519, and > chacha20+poly1305, the developers have commented about the possibility > of building an RFC non-compliant OpenSSH without OpenSSL. > > If you search through the mailing list archive, I believe you chould see > some references to this. There are also commtnes in the CVS commits > regarding this. And, I believe Damien mentioned about this in his > interview on bsdnow.tv. > > In one of the CVS commits, I noticed that there is support for falling > back on libc for digest support when building without OpenSSL, but I > don't recall if this is both MD5 and SHA1 or not. > > -- > Iain Morgan Hi Iain, sha1 and md5 are not used in nacl. You need only sha256 or sha512, eg: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/hash.c?rev=1.3;content-type=text%2Fplain Best regards, Daniel > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mancha1 at hush.com Fri Mar 7 07:36:06 2014 From: mancha1 at hush.com (mancha) Date: Thu, 6 Mar 2014 20:36:06 +0000 (UTC) Subject: [RFC] Add hash token to ControlPath References: <20140306183721.6EDA920106@smtp.hushmail.com> <20140306191301.GB6663@linux124.nas.nasa.gov> Message-ID: Iain Morgan nas.nasa.gov> writes: > > On Thu, Mar 06, 2014 at 18:37:21 +0000, mancha wrote: > > Hi. > > > > Last night on an irc openssh channel, a user brought up a use > > case involving cluster trees and very descriptive (i.e. long) > > hierarchical hostnames. > > > > To make a long story short, his ControlPath (~/.ssh/control-master > > /%r %h:%p) was bumping up against UNIX_PATH_MAX. > > > > Attached patch adds a new percent-token (%H) that expands to the > > sha1 digest of the concatenation of host (%h) + port (%p) + remote > > user (%r). The token's expanded length is a fixed 40 characters > > and, barring digest collision, provides uniqueness. > > > > The patch was built against 6.5p1 but applies (with harmless > > offsets) to OpenBSD HEAD. > > > > --mancha > > I suppose the IP address of the destination host is not known at the > time that the socket is created or initially accessed; but if it is, > adding a macro for the IP address might be an alternative approach. > > With regard to your suggestion, it might also be worthwhile including > the client hostname in the hash to cover scenarios where the sockets are > created in shared filesystems. I'm also a little hesitant about using > %H; in analogy to %l and %L, %H should be the first component of the > destinations's name. Perhaps %M or %S? > > I'm not sure if the work being done to allow OpenSSH to be built without > OpenSSL includes SHA-1 support. I assume that it does, but I haven't > gottent around to looking at the code. If it doesn't, it might be > necessary to use MD5 instead. > Iain, many thanks for your good comments. I've made the following changes: 1. Digest is based on lhost(%l) + rhost(%h) + rport(%p) + ruser(%r) 2. Macro is %D 3. ssh_digest_* wrappers are used to future proof If SHA1 is no longer supported in the future, MD5 can be used by changing two lines. Patch: http://sf.net/projects/mancha/files/misc/openssh-6.5p1-mux-hash.diff --mancha From kevin.brott at gmail.com Fri Mar 7 07:50:40 2014 From: kevin.brott at gmail.com (Kevin Brott) Date: Thu, 6 Mar 2014 12:50:40 -0800 Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: So - trying to build openssh-SNAP-20140307.tar.gz on RHEL 4 (SP8) x86_64 and I'm hitting a wall in 'make tests': ... ok connection multiplexing run test reexec.sh ... test config passing reexec tests: proto 1 reexec tests: proto 2 test reexec fallback FATAL: no sshd running on port 4242 gmake[1]: *** [t-exec] Error 1 gmake[1]: Leaving directory `/var/tmp/ssh/openssh/regress' gmake: *** [tests] Error 2 None of the regress/failed*.logs tell me anything more than there's no sshd running on port 4242. i.e. failed-sshd.log: trace: wait for sshd Received signal 15; terminating. debug3: channel 0: will not send data after close debug2: channel 0: rcvd close Received disconnect from 127.0.0.1: 11: disconnected by user debug1: do_cleanup FATAL: no sshd running on port 4242 trace: wait for sshd Received signal 15; terminating. debug3: channel 0: will not send data after close debug2: channel 0: rcvd close Received disconnect from 127.0.0.1: 11: disconnected by user debug1: do_cleanup FATAL: no sshd running on port 4242 FAIL: no sshd running on port 4242 I thought it might be memory - but bumping it up in the VM doesn't change anything and it doesn't seem to be selinux, or any open port conflicts (some of my favourite stumbling blocks). The weirder thing is that I got this to work in the i386 test box just fine. Thoughts? From naddy at mips.inka.de Fri Mar 7 08:02:28 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Thu, 6 Mar 2014 21:02:28 +0000 (UTC) Subject: Without OpenSSL? References: <20140306200023.GC6663@linux124.nas.nasa.gov> Message-ID: On 2014-03-06, Iain Morgan wrote: > In one of the CVS commits, I noticed that there is support for falling > back on libc for digest support when building without OpenSSL, but I > don't recall if this is both MD5 and SHA1 or not. It's all of MD5, RIPEMD160, SHA1, SHA256, SHA384, SHA512 (digest-libc.c). I gave it a try when it was committed. It builds and runs on OpenBSD. -- Christian "naddy" Weisgerber naddy at mips.inka.de From imorgan at nas.nasa.gov Fri Mar 7 08:41:39 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 6 Mar 2014 13:41:39 -0800 Subject: Without OpenSSL? In-Reply-To: References: <20140306200023.GC6663@linux124.nas.nasa.gov> Message-ID: <20140306214139.GD6663@linux124.nas.nasa.gov> On Thu, Mar 06, 2014 at 21:02:28 +0000, Christian Weisgerber wrote: > On 2014-03-06, Iain Morgan wrote: > > > In one of the CVS commits, I noticed that there is support for falling > > back on libc for digest support when building without OpenSSL, but I > > don't recall if this is both MD5 and SHA1 or not. > > It's all of MD5, RIPEMD160, SHA1, SHA256, SHA384, SHA512 (digest-libc.c). > I gave it a try when it was committed. It builds and runs on OpenBSD. > > -- > Christian "naddy" Weisgerber naddy at mips.inka.de This assumes that the native libc supports all of those. That may be the case for most operating systems, but I wouldn't be surprised if there are some that only implement MD5. -- Iain Morgan From tim at multitalents.net Fri Mar 7 09:51:33 2014 From: tim at multitalents.net (Tim Rice) Date: Thu, 6 Mar 2014 14:51:33 -0800 (PST) Subject: [RFC] Add hash token to ControlPath In-Reply-To: References: <20140306183721.6EDA920106@smtp.hushmail.com> Message-ID: On Thu, 6 Mar 2014, mancha wrote: > Apologies but it seems the ML strips attachments. Rather than risk > whitespace debacles with inline patches, I've placed it here: The list will pass text/plain and text/x-patch attachements. > http://sf.net/projects/mancha/files/misc/openssh-6.5p1-mux-hash.diff You may want to open a bug at https://bugzilla.mindrot.org/ -- Tim Rice Multitalents tim at multitalents.net From dtucker at zip.com.au Fri Mar 7 10:02:01 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 7 Mar 2014 10:02:01 +1100 Subject: [RFC] Add hash token to ControlPath In-Reply-To: References: <20140306183721.6EDA920106@smtp.hushmail.com> <20140306191301.GB6663@linux124.nas.nasa.gov> Message-ID: On Fri, Mar 7, 2014 at 7:36 AM, mancha wrote: [...] > 1. Digest is based on lhost(%l) + rhost(%h) + rport(%p) + ruser(%r) > 2. Macro is %D Here's the currently implemented % expansions across all the tools (the intention being to prevent any new conflicts or inconsistencies). http://www.dtucker.net/openssh/percent_expand_opts.html -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Fri Mar 7 10:43:38 2014 From: tim at multitalents.net (Tim Rice) Date: Thu, 6 Mar 2014 15:43:38 -0800 (PST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: On Thu, 6 Mar 2014, Kevin Brott wrote: > So - trying to build openssh-SNAP-20140307.tar.gz on RHEL 4 (SP8) x86_64 > and I'm hitting a wall in 'make tests': > > ... > ok connection multiplexing > run test reexec.sh ... > test config passing > reexec tests: proto 1 > reexec tests: proto 2 > test reexec fallback > FATAL: no sshd running on port 4242 > gmake[1]: *** [t-exec] Error 1 > gmake[1]: Leaving directory `/var/tmp/ssh/openssh/regress' > gmake: *** [tests] Error 2 > [snip] > The weirder thing is that I got this to work in the i386 test box just > fine. Thoughts? You can use "make LTESTS=reexec tests" to just run the single test. sshd gets started by test-exec.sh, so you could put a set -x in there to capture the actual command line used the try it manually or under strace to see what's going on. -- Tim Rice Multitalents tim at multitalents.net From mancha1 at hush.com Fri Mar 7 15:11:17 2014 From: mancha1 at hush.com (mancha) Date: Fri, 7 Mar 2014 04:11:17 +0000 (UTC) Subject: [RFC] Add hash token to ControlPath References: <20140306183721.6EDA920106@smtp.hushmail.com> <20140306191301.GB6663@linux124.nas.nasa.gov> Message-ID: Darren Tucker zip.com.au> writes: > > On Fri, Mar 7, 2014 at 7:36 AM, mancha hush.com> wrote: > [...] > > 1. Digest is based on lhost(%l) + rhost(%h) + rport(%p) + ruser(%r) > > 2. Macro is %D > > Here's the currently implemented % expansions across all the tools > (the intention being to prevent any new conflicts or inconsistencies). > > http://www.dtucker.net/openssh/percent_expand_opts.html > That table was really helpful - thanks. I've settled on %m (for "message digest") to avoid any confusion. New patch is up: http://sf.net/projects/mancha/files/misc/openssh-6.5p1-mux-hash.diff --mancha From sunil.saraff86 at gmail.com Fri Mar 7 00:26:30 2014 From: sunil.saraff86 at gmail.com (Sunil Saraff) Date: Thu, 6 Mar 2014 18:56:30 +0530 Subject: Is cipher "3des-ctr" supported by openssh? Message-ID: Hi, Is cipher "3des-ctr" supported by openssh? It is not mentioned in the list of supported ciphers in the man page of ssh_config: Thanks, Sunil Ciphers Specifies the ciphers allowed for protocol version 2 in order of preference. Multiple ciphers must be comma-separated. The supported ciphers are ''3des-cbc'', ''aes128-cbc'', ''aes192-cbc'', ''aes256-cbc'', ''aes128-ctr'', ''aes192-ctr'', ''aes256-ctr'', ''arcfour128'', ''arcfour256'', ''arcfour'', ''blowfish-cbc'', and ''cast128-cbc''. The default is: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc, aes256-cbc,arcfour From mfriedl at gmail.com Sat Mar 8 03:14:52 2014 From: mfriedl at gmail.com (Markus Friedl) Date: Fri, 7 Mar 2014 17:14:52 +0100 Subject: Is cipher "3des-ctr" supported by openssh? In-Reply-To: References: Message-ID: <355C4213-1894-4784-B32A-AD5AC3713B77@gmail.com> It's not supported. Use AES-ctr instead. > Am 06.03.2014 um 14:26 schrieb Sunil Saraff : > > Hi, > > Is cipher "3des-ctr" supported by openssh? > > It is not mentioned in the list of supported ciphers in the man page of > ssh_config: > > Thanks, Sunil > > Ciphers > > Specifies the ciphers allowed for protocol version 2 in order of > preference. Multiple ciphers must be comma-separated. The supported ciphers > are ''3des-cbc'', ''aes128-cbc'', ''aes192-cbc'', ''aes256-cbc'', > ''aes128-ctr'', ''aes192-ctr'', ''aes256-ctr'', ''arcfour128'', > ''arcfour256'', ''arcfour'', ''blowfish-cbc'', and ''cast128-cbc''. The > default is: > > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc, aes256-cbc,arcfour > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From sunil.saraff86 at gmail.com Mon Mar 10 17:15:43 2014 From: sunil.saraff86 at gmail.com (Sunil Saraff) Date: Mon, 10 Mar 2014 11:45:43 +0530 Subject: Is cipher "3des-ctr" supported by openssh? In-Reply-To: <355C4213-1894-4784-B32A-AD5AC3713B77@gmail.com> References: <355C4213-1894-4784-B32A-AD5AC3713B77@gmail.com> Message-ID: Thanks for the reply. Any plans to add this in future? Regards, Sunil On Fri, Mar 7, 2014 at 9:44 PM, Markus Friedl wrote: > It's not supported. Use AES-ctr instead. > > > > > Am 06.03.2014 um 14:26 schrieb Sunil Saraff : > > > > Hi, > > > > Is cipher "3des-ctr" supported by openssh? > > > > It is not mentioned in the list of supported ciphers in the man page of > > ssh_config: > > > > Thanks, Sunil > > > > Ciphers > > > > Specifies the ciphers allowed for protocol version 2 in order of > > preference. Multiple ciphers must be comma-separated. The supported > ciphers > > are ''3des-cbc'', ''aes128-cbc'', ''aes192-cbc'', ''aes256-cbc'', > > ''aes128-ctr'', ''aes192-ctr'', ''aes256-ctr'', ''arcfour128'', > > ''arcfour256'', ''arcfour'', ''blowfish-cbc'', and ''cast128-cbc''. The > > default is: > > > > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc, > aes256-cbc,arcfour > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From mstone at mathom.us Mon Mar 10 22:15:45 2014 From: mstone at mathom.us (Michael Stone) Date: Mon, 10 Mar 2014 07:15:45 -0400 Subject: Is cipher "3des-ctr" supported by openssh? In-Reply-To: References: <355C4213-1894-4784-B32A-AD5AC3713B77@gmail.com> Message-ID: <36ed9a64-a845-11e3-aecf-00163eeb5320@msgid.mathom.us> On Mon, Mar 10, 2014 at 11:45:43AM +0530, you wrote: >Thanks for the reply. Any plans to add this in future? I'm curious why you want a new 3des mode with limited compatibility in 2014. Mike Stone From carsten at wieschiolek.de Mon Mar 10 23:02:57 2014 From: carsten at wieschiolek.de (Carsten Wieschiolek) Date: Mon, 10 Mar 2014 13:02:57 +0100 Subject: Bug: Environment vars are changed before use (locale LANG, LC_*) In-Reply-To: References: <530CC263.1000106@wieschiolek.de> <53146306.4070408@wieschiolek.de> Message-ID: <531DA9F1.4060804@wieschiolek.de> Thanks Damien This was a very valuable reply. With this I could tackle the problem. Maybe this info could be added to the man page? With Best Regards Carsten Am 03.03.2014 18:53, schrieb Damien Miller: > On Mon, 3 Mar 2014, Carsten Wieschiolek wrote: > >> Hi Damien! >> >> Thanks for the friendly reply! >> >> I did a few more tests to investigate the matter further based on >> your comments. The bottom line is, that the settings from the file >> "environment" in the .ssh directory are not considered at all. The >> values from the calling SHELL have precedence over the entries in the >> file, which makes the file quite useless. Am I overlooking something >> important? > The order is something like: > > 1. Environment variables passed by SendEnv/AcceptEnv > 2. Environment variables specified by pam_env > 3. ~/.ssh/enviornment > 4. Environment variables set by the shell > > (I might have #2 and #3 reversed here) > > #1, #2 and #3 all prepare the environment that the shell is executed with, > so naturally anything the shell does will overrride them. > > As for how to fix it. One way is to rename the environment variables > and then have your shell initialisation put them back. E.g. > > preferred_LANG=en_AU:en > > in ~/.ssh/enviornment, and > > test -z "$preferred_LANG" && LANG="$preferred_LANG" > export LANG > > in your shell initialisation. > > -d > From aris at 0xbadc0de.be Mon Mar 10 23:08:30 2014 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Mon, 10 Mar 2014 13:08:30 +0100 Subject: Is cipher "3des-ctr" supported by openssh? In-Reply-To: <36ed9a64-a845-11e3-aecf-00163eeb5320@msgid.mathom.us> References: <355C4213-1894-4784-B32A-AD5AC3713B77@gmail.com> <36ed9a64-a845-11e3-aecf-00163eeb5320@msgid.mathom.us> Message-ID: <531DAB3E.8070300@0xbadc0de.be> The only strong point of 3des-cbc is that it's mandatory in the specifications and can be found everywhere. aes128-ctr is stronger, faster and ubiquitous, I see no reason there should be a 3des-ctr which would be slow and implemented nowhere (and less secure). Aris Le 10/03/14 12:15, Michael Stone a ?crit : > On Mon, Mar 10, 2014 at 11:45:43AM +0530, you wrote: >> Thanks for the reply. Any plans to add this in future? > > I'm curious why you want a new 3des mode with limited compatibility in > 2014. > > Mike Stone > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From mfriedl at gmail.com Mon Mar 10 23:37:44 2014 From: mfriedl at gmail.com (Markus Friedl) Date: Mon, 10 Mar 2014 13:37:44 +0100 Subject: Is cipher "3des-ctr" supported by openssh? In-Reply-To: References: <355C4213-1894-4784-B32A-AD5AC3713B77@gmail.com> Message-ID: Not planned. Why? > Am 10.03.2014 um 07:15 schrieb Sunil Saraff : > > Thanks for the reply. Any plans to add this in future? > > Regards, > Sunil > > >> On Fri, Mar 7, 2014 at 9:44 PM, Markus Friedl wrote: >> It's not supported. Use AES-ctr instead. >> >> >> >> > Am 06.03.2014 um 14:26 schrieb Sunil Saraff : >> > >> > Hi, >> > >> > Is cipher "3des-ctr" supported by openssh? >> > >> > It is not mentioned in the list of supported ciphers in the man page of >> > ssh_config: >> > >> > Thanks, Sunil >> > >> > Ciphers >> > >> > Specifies the ciphers allowed for protocol version 2 in order of >> > preference. Multiple ciphers must be comma-separated. The supported ciphers >> > are ''3des-cbc'', ''aes128-cbc'', ''aes192-cbc'', ''aes256-cbc'', >> > ''aes128-ctr'', ''aes192-ctr'', ''aes256-ctr'', ''arcfour128'', >> > ''arcfour256'', ''arcfour'', ''blowfish-cbc'', and ''cast128-cbc''. The >> > default is: >> > >> > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, >> > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc, aes256-cbc,arcfour >> > _______________________________________________ >> > openssh-unix-dev mailing list >> > openssh-unix-dev at mindrot.org >> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From sachin3072004 at gmail.com Wed Mar 12 05:11:53 2014 From: sachin3072004 at gmail.com (Sachin Gupta) Date: Tue, 11 Mar 2014 11:11:53 -0700 Subject: Upgrading openssh to 6.5 on centOS 5 machine Message-ID: Hello Everyone, I am a newbie. I am supposed to upgrade openssh on a centOS machine. Following are the current versions of openssh and centOS. /tmp# /usr/sbin/sshd -V OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 /tmp# rpm -q centos-release centos-release-5-2.el5.centos I have already tried the following link. http://fr2.rpmfind.net/linux/rpm2html/search.php?query=openssh I am unable to find out the right RPM for centOS 5.0. Can you please point me to the right RPM ? Thanks Sachin From loganaden at gmail.com Wed Mar 12 05:42:05 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Tue, 11 Mar 2014 22:42:05 +0400 Subject: Upgrading openssh to 6.5 on centOS 5 machine In-Reply-To: References: Message-ID: On Tue, Mar 11, 2014 at 10:11 PM, Sachin Gupta wrote: > Hello Everyone, > > I am a newbie. > I am supposed to upgrade openssh on a centOS machine. > Following are the current versions of openssh and centOS. > > /tmp# /usr/sbin/sshd -V > OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 > > /tmp# rpm -q centos-release > centos-release-5-2.el5.centos > > I have already tried the following link. > http://fr2.rpmfind.net/linux/rpm2html/search.php?query=openssh > > I am unable to find out the right RPM for centOS 5.0. > Can you please point me to the right RPM ? Hi Sachin. I believe that it's a distro-based issue. This mailing list is concerned about openssh itself. I think that you should subscribe to centos mailing list (I'm on the centos mailing list), and ask the question. Hope it helps. > > Thanks > Sachin > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From imorgan at nas.nasa.gov Wed Mar 12 06:51:32 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 11 Mar 2014 12:51:32 -0700 Subject: Upgrading openssh to 6.5 on centOS 5 machine In-Reply-To: References: Message-ID: <20140311195132.GB28845@linux124.nas.nasa.gov> On Tue, Mar 11, 2014 at 11:11:53 -0700, Sachin Gupta wrote: > Hello Everyone, > > I am a newbie. > I am supposed to upgrade openssh on a centOS machine. > Following are the current versions of openssh and centOS. > > /tmp# /usr/sbin/sshd -V > OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 > > /tmp# rpm -q centos-release > centos-release-5-2.el5.centos > > I have already tried the following link. > http://fr2.rpmfind.net/linux/rpm2html/search.php?query=openssh > > I am unable to find out the right RPM for centOS 5.0. > Can you please point me to the right RPM ? > > Thanks > Sachin You can build your own RPMs based on the .spec file included in the source distribution of OpenSSH. Grab a copy of the current source tarball and look at README.platform and contrib/redhat/openssh.spec. -- Iain Morgan From sachin3072004 at gmail.com Wed Mar 12 12:41:48 2014 From: sachin3072004 at gmail.com (Sachin Gupta) Date: Tue, 11 Mar 2014 18:41:48 -0700 Subject: Upgrading openssh to 6.5 on centOS 5 machine In-Reply-To: <20140311195132.GB28845@linux124.nas.nasa.gov> References: <20140311195132.GB28845@linux124.nas.nasa.gov> Message-ID: Thanks lain for your help !!! I have created and installed openssh 6.5 on my box. But my sshd exits with following message. /etc/ssh/sshd_config: line 10: Bad configuration option: PermitPAMUserChange /etc/ssh/sshd_config: terminating, 1 bad configuration options. Please help. Thanks Sachin On Tue, Mar 11, 2014 at 12:51 PM, Iain Morgan wrote: > On Tue, Mar 11, 2014 at 11:11:53 -0700, Sachin Gupta wrote: > > Hello Everyone, > > > > I am a newbie. > > I am supposed to upgrade openssh on a centOS machine. > > Following are the current versions of openssh and centOS. > > > > /tmp# /usr/sbin/sshd -V > > OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 > > > > /tmp# rpm -q centos-release > > centos-release-5-2.el5.centos > > > > I have already tried the following link. > > http://fr2.rpmfind.net/linux/rpm2html/search.php?query=openssh > > > > I am unable to find out the right RPM for centOS 5.0. > > Can you please point me to the right RPM ? > > > > Thanks > > Sachin > > You can build your own RPMs based on the .spec file included in the > source distribution of OpenSSH. Grab a copy of the current source > tarball and look at README.platform and contrib/redhat/openssh.spec. > > -- > Iain Morgan > From djm at mindrot.org Wed Mar 12 14:17:19 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 12 Mar 2014 14:17:19 +1100 (EST) Subject: Upgrading openssh to 6.5 on centOS 5 machine In-Reply-To: References: <20140311195132.GB28845@linux124.nas.nasa.gov> Message-ID: On Tue, 11 Mar 2014, Sachin Gupta wrote: > Thanks lain for your help !!! > > I have created and installed openssh 6.5 on my box. > But my sshd exits with following message. > > /etc/ssh/sshd_config: line 10: Bad configuration option: PermitPAMUserChange > /etc/ssh/sshd_config: terminating, 1 bad configuration options. That's not, and never was, an OpenSSH option. Your previous sshd must have not been OpenSSH or been OpenSSH+someone's patches. -d From phil.pennock at globnix.org Wed Mar 12 15:22:42 2014 From: phil.pennock at globnix.org (Phil Pennock) Date: Wed, 12 Mar 2014 00:22:42 -0400 Subject: Upgrading openssh to 6.5 on centOS 5 machine In-Reply-To: References: <20140311195132.GB28845@linux124.nas.nasa.gov> Message-ID: <20140312042242.GA85142@redoubt.spodhuis.org> On 2014-03-11 at 18:41 -0700, Sachin Gupta wrote: > Thanks lain for your help !!! > > I have created and installed openssh 6.5 on my box. > But my sshd exits with following message. > > /etc/ssh/sshd_config: line 10: Bad configuration option: PermitPAMUserChange > /etc/ssh/sshd_config: terminating, 1 bad configuration options. > > Please help. Audit your existing install to find out which patches had been applied. If you connect to port 22 with a plain TCP connection (netcat, nc, or at a pinch telnet[*]) then you should see a list of patches as part of the connection banner. Or invoke the existing sshd, with a full path and the -d option and look at the first few lines of output. Or do both, and also use your package management tools (rpm) to look at changelog details for the previously-installed software to see what might have been added. You probably want to examine the third-party patch available from: http://grid.ncsa.illinois.edu/ssh/ If you have enabled this option and have been running with a very old sshd then you should also fix your site's operational processes to make sure that you're getting vendor security notifications for software and patches which you rely upon. There was a security advisory last April: http://grid.ncsa.illinois.edu/ssh/pamuserchange-2013-01.adv If you're not building an unmodified sshd (or working on getting a patch you developed yourself incorporated) then you probably want to look elsewhere for vendor support -- the volunteers here aren't really the people to ask help deal with issues from third-party modifications. -Phil [*] pedants: yes, I know telnet is a protocol layered above TCP; still, the telnet client is the easiest and most readily and portably available and mostly works for people From loganaden at gmail.com Wed Mar 12 15:47:16 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Wed, 12 Mar 2014 08:47:16 +0400 Subject: Upgrading openssh to 6.5 on centOS 5 machine In-Reply-To: References: <20140311195132.GB28845@linux124.nas.nasa.gov> Message-ID: On Wed, Mar 12, 2014 at 7:17 AM, Damien Miller wrote: > On Tue, 11 Mar 2014, Sachin Gupta wrote: > >> Thanks lain for your help !!! >> >> I have created and installed openssh 6.5 on my box. >> But my sshd exits with following message. >> >> /etc/ssh/sshd_config: line 10: Bad configuration option: PermitPAMUserChange >> /etc/ssh/sshd_config: terminating, 1 bad configuration options. > > That's not, and never was, an OpenSSH option. Your previous sshd must have > not been OpenSSH or been OpenSSH+someone's patches. Sachin, I'd be very careful. I would suggest that you ask the vendor for an RPM that ships a plain version of OpenSSH 6.5, without 3rd party patches. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From kevin.brott at gmail.com Fri Mar 14 05:21:08 2014 From: kevin.brott at gmail.com (Kevin Brott) Date: Thu, 13 Mar 2014 11:21:08 -0700 Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: Running test-exec.sh with the set -x in it shows it trying to run this command line: /usr/src/openssh/regress/sshd -f /usr/src/openssh/regress/sshd_config -E/usr/src/openssh/regress/ssh.log Yet, watching the process table during that part of make tests shows that command never actually executed, so the pidfile being tested for never materializes. Simply manually running that command in another window while the test is waiting for the pidfile, gets past the failure and gets 'make tests' to cleanly finish to 'all tests passed'. So I'm not sure exactly what's going south here, it's almost as if it's not really running the command, or can't - but it's not throwing any errors as to why. ===== On Thu, Mar 6, 2014 at 3:43 PM, Tim Rice wrote: > On Thu, 6 Mar 2014, Kevin Brott wrote: > > > So - trying to build openssh-SNAP-20140307.tar.gz on RHEL 4 (SP8) x86_64 > > and I'm hitting a wall in 'make tests': > > > > ... > > ok connection multiplexing > > run test reexec.sh ... > > test config passing > > reexec tests: proto 1 > > reexec tests: proto 2 > > test reexec fallback > > FATAL: no sshd running on port 4242 > > gmake[1]: *** [t-exec] Error 1 > > gmake[1]: Leaving directory `/var/tmp/ssh/openssh/regress' > > gmake: *** [tests] Error 2 > > > [snip] > > The weirder thing is that I got this to work in the i386 test box just > > fine. Thoughts? > > You can use "make LTESTS=reexec tests" to just run the single test. > sshd gets started by test-exec.sh, so you could put a set -x in there > to capture the actual command line used the try it manually or > under strace to see what's going on. > > -- > Tim Rice Multitalents > tim at multitalents.net > > > -- # include /* Kevin Brott */ From djm at mindrot.org Sat Mar 15 13:39:49 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Mar 2014 13:39:49 +1100 (EST) Subject: Call for testing: OpenSSH 6.6 In-Reply-To: References: Message-ID: On Thu, 13 Mar 2014, Kevin Brott wrote: > Running test-exec.sh with the set -x in it shows it trying to run this > command line: > /usr/src/openssh/regress/sshd -f /usr/src/openssh/regress/sshd_config > -E/usr/src/openssh/regress/ssh.log > Yet, watching the process table during that part of make tests shows that > command never actually executed, so the pidfile being tested for never > materializes. > > Simply manually running that command in another window while the test is > waiting for the pidfile, gets past the failure and gets 'make tests' to > cleanly finish to 'all tests passed'. > > So I'm not sure exactly what's going south here, it's almost as if it's not > really running the command, or can't - but it's not throwing any errors as > to why. I installed CentOS 4.8 from some godforsaken mirror site and was able to reproduce this - it turns out to be a race condition in the test itself: adding a "sleep 1" after each "kill" statement makes the test pass. We need a better way of handling this in the tests, perhaps polling for sshd's pidfile being deleted. -d From nheghathivhistha at gmail.com Sun Mar 16 03:41:37 2014 From: nheghathivhistha at gmail.com (David Kredba) Date: Sat, 15 Mar 2014 17:41:37 +0100 Subject: Gcc-4.9.0 trunk revision 208516 cannot compile openssh package with -flto Message-ID: Hello, Could I please ask you for help? I opened a case in GCC Bugzilla and got reply that -fpie have to be used to get it compiled. Now it fails for me with: x86_64-pc-linux-gnu-gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -pie -lssh -lopenbsd-compat -lssl -lcrypto -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread umac.c:1193:3: warning: type of 'umac_ctx' does not match original declaration } umac_ctx; ^ ./umac.c:1193:3: note: previously declared here } umac_ctx; ^ /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/net-misc/openssh-6.5_p1-r1/temp/ccMU2kiP.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC /var/tmp/portage/net-misc/openssh-6.5_p1-r1/temp/ccMU2kiP.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:150: recipe for target 'ssh' failed make: *** [ssh] Error 1 ^[[31;01m*^[[0m ERROR: net-misc/openssh-6.5_p1-r1::gentoo failed (compile phase): ^[[31;01m*^[[0m emake failed gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0-alpha20140311/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20140311/work/gcc-4.9-20140311/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0-alpha20140311 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20140311 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20140311/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20140311/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20140311/python --enable-languages=c,c++,java,go,objc,obj-c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.0_alpha20140311' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-java-awt=gtk --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.9.0-alpha20140311 20140312 (experimental) [trunk revision 208516] (Gentoo 4.9.0_alpha20140311) I am attaching config.log and build.log, both gzipped. Can this be checked by configure? Like if -flto* found then to use -fpie too? Thank you in advance. Best regards, David. From djm at mindrot.org Sun Mar 16 07:30:25 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Mar 2014 07:30:25 +1100 (EST) Subject: Gcc-4.9.0 trunk revision 208516 cannot compile openssh package with -flto In-Reply-To: References: Message-ID: On Sat, 15 Mar 2014, David Kredba wrote: > Hello, > Could I please ask you for help? > > I opened a case in GCC Bugzilla and got reply that -fpie have to be > used to get it compiled. > > Now it fails for me with: > > x86_64-pc-linux-gnu-gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o > sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o > roaming_client.o -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin > -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native > -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now > -Wl,-z,noexecstack -fstack-protector-strong -flto=4 > -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe > -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -pie -lssh > -lopenbsd-compat -lssl -lcrypto -ldl -lutil -lz -lnsl -lcrypt > -lresolv -lpthread There are a whole lot of options in here that were not added by OpenSSH's configure. If you are specifying CFLAGS then it is up to you to provide a coherent set. > I am attaching config.log and build.log, both gzipped. There were no attachments. The list software only accepts text attachments because of past incidents with spammers. If they are large then your best bet is to put them on a website somewhere (e.g. pastebin). > Can this be checked by configure? Like if -flto* found then to use -fpie too? We can't check every possible option provided by the user; the defaults are intended to work, but if you use others then you need to ensure they are coherent. - From djm at cvs.openbsd.org Sun Mar 16 08:38:59 2014 From: djm at cvs.openbsd.org (Damien Miller) Date: Sat, 15 Mar 2014 15:38:59 -0600 (MDT) Subject: Announce: OpenSSH 6.6 released Message-ID: <201403152138.s2FLcxWc003855@cvs.openbsd.org> OpenSSH 6.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Changes since OpenSSH 6.6 ========================= This is primarily a bugfix release. Security: * sshd(8): when using environment passing with a sshd_config(5) AcceptEnv pattern with a wildcard. OpenSSH prior to 6.6 could be tricked into accepting any enviornment variable that contains the characters before the wildcard character. New / changed features: * ssh(1), sshd(8): this release removes the J-PAKE authentication code. This code was experimental, never enabled and had been unmaintained for some time. * ssh(1): when processing Match blocks, skip 'exec' clauses other clauses predicates failed to match. * ssh(1): if hostname canonicalisation is enabled and results in the destination hostname being changed, then re-parse ssh_config(5) files using the new destination hostname. This gives 'Host' and 'Match' directives that use the expanded hostname a chance to be applied. Bugfixes: * ssh(1): avoid spurious "getsockname failed: Bad file descriptor" in ssh -W. bz#2200, debian#738692 * sshd(8): allow the shutdown(2) syscall in seccomp-bpf and systrace sandbox modes, as it is reachable if the connection is terminated during the pre-auth phase. * ssh(1), sshd(8): fix unsigned overflow that in SSH protocol 1 bignum parsing. Minimum key length checks render this bug unexploitable to compromise SSH 1 sessions. * sshd_config(5): clarify behaviour of a keyword that appears in multiple matching Match blocks. bz#2184 * ssh(1): avoid unnecessary hostname lookups when canonicalisation is disabled. bz#2205 * sshd(8): avoid sandbox violation crashes in GSSAPI code by caching the supported list of GSSAPI mechanism OIDs before entering the sandbox. bz#2107 * ssh(1): fix possible crashes in SOCKS4 parsing caused by assumption that the SOCKS username is nul-terminated. * ssh(1): fix regression for UsePrivilegedPort=yes when BindAddress is not specified. * ssh(1), sshd(8): fix memory leak in ECDSA signature verification. * ssh(1): fix matching of 'Host' directives in ssh_config(5) files to be case-insensitive again (regression in 6.5). Portable OpenSSH: * sshd(8): don't fatal if the FreeBSD Capsicum is offered by the system headers and libc but is not supported by the kernel. * Fix build using the HP-UX compiler. Checksums: ========== - SHA1 (openssh-6.6.tar.gz) = bf932d798324ff2502409d3714d0ad8d65c7e1e7 - SHA256 (openssh-6.6.tar.gz) = jaSJE5aiQRm+91dV6EvVGr/ozo33tbxyjjFSiu+Cy80= - SHA1 (openssh-6.6p1.tar.gz) = b850fd1af704942d9b3c2eff7ef6b3a59b6a6b6e - SHA256 (openssh-6.6p1.tar.gz) = SMHwZktFNIdQOABMxPNVW4MpwqgcHfSNtcUXgA3iA7s= Please note that the PGP key used to sign releases was recently rotated. The new key has been signed by the old key to provide continuity. It is available from the mirror sites as RELEASE_KEY.asc. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From abhilashtabraham at gmail.com Mon Mar 17 15:55:00 2014 From: abhilashtabraham at gmail.com (abhilash abraham) Date: Mon, 17 Mar 2014 10:25:00 +0530 Subject: Query on window adjust in SSH server Message-ID: Hi, I have a problem regarding window adjust, in the SSH server. I was trying to get a file of 400K from a system, via SFTP, which has old version of openSSH [v2.0 or so] in it. I'm using Windows client, filezilla, to get thre file. Once it reaches ~12k, the transfer gets halted. On debugging I could find that it has reached the maximum window size in the server and the client is never again sending the window adjust message. In RFC, I couldn't find anything about handling this situation. Can you please let me know whether the server has the 'right' to adjust the window size without the message from client. Or is there any reason for the client not sending the adjust message[like its not aware of window exhausted in server]? -- ?????????????? ??? From singh.ravipratap88 at gmail.com Mon Mar 17 21:48:45 2014 From: singh.ravipratap88 at gmail.com (RAVI PRATAP Singh) Date: Mon, 17 Mar 2014 16:18:45 +0530 Subject: protocol error : expected control record Message-ID: Hi All, During scp, I am seeing this message protocol error : expected control record This message came because scp sink was expecting the message starting from 'C' or 'D' , something like C0644 299 group or D0755 0 docs but during dns query we were printing "Using IP address" message on the stdout. So , the message in the buffer was "Using IP address" and thus message "protocol error : expected control record" was thrown. Is openssh scp should always expect 'Cmmmm' or 'Dmmmm' messages ? Is fix available for taking care scenario where on stdout something is printed. Thanks Ravi Pratap From brian at brutex.de Tue Mar 18 03:12:50 2014 From: brian at brutex.de (Brian Rosenberger) Date: Mon, 17 Mar 2014 17:12:50 +0100 Subject: internal-sftp stuck on 'ls' with chrootdirectory Message-ID: <009701cf41fb$c0d07f40$42717dc0$@brutex.de> Hi all, I am using Match directive and internal-sftp to chroot sftp users into their directory. Connection and login works. I can change directories and put/get files. Also logging of the internal sftp-process works (created a /dev/log socket inside the chroot). As soon as I use the 'ls' command, nothing happens and the the process gets stuck. Listing files does work as soon as I remove the chrootdirectory directive. Configuration details: >From the end of the /etc/ssh/sshd_config: Subsystem sftp internal-sftp Match User p16012 ChrootDirectory /srv/www/xxxxx.de ForceCommand internal-sftp -l VERBOSE -f LOCAL6 I have created an additional socket for the rsyslog deamon inside the chroot directory and logging works fine: Mar 17 16:42:24 nina internal-sftp[6749]: session opened for local user p16012 from [84.xx.xxx.66] Mar 17 16:42:24 nina internal-sftp[6749]: received client version 3 Mar 17 16:42:24 nina internal-sftp[6749]: realpath "." Mar 17 16:42:27 nina internal-sftp[6749]: opendir "/" >From the auth.log I get: Mar 17 16:42:24 nina sshd[6745]: Accepted password for p16012 from 84.xx.xxx.60 port 50295 ssh2 Mar 17 16:42:24 nina sshd[6745]: pam_unix(sshd:session): session opened for user p16012 by (uid=0) Mar 17 16:42:24 nina sshd[6748]: subsystem request for sftp by user p16012 I also did strace the internal-sftp process: root at nina:/srv/www/xxxxx.de# strace -s 50 -a 200 -p 6846 Process 6846 attached - interrupt to quit select(2, [0], [], NULL, NULL) = 1 (in [0]) read(0, "\0\0\0\20\v\0\0\177t\0\0\0\7/htdocs", 16384) = 20 time([1395071933]) = 1395071933 socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0 sendto(3, "<182>Mar 17 16:58:53 internal-sftp[6846]: opendir "..., 59, MSG_NOSIGNAL, NULL, 0) = 59 close(3) = 0 open("/htdocs", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 select(2, [0], [1], NULL, NULL) = 1 (out [1]) write(1, "\0\0\0\rf\0\0\177t\0\0\0\4\0\0\0\0", 17) = 17 select(2, [0], [], NULL, NULL) = 1 (in [0]) read(0, "\0\0\0\r\f\0\0\177u\0\0\0\4\0\0\0\0", 16384) = 17 getdents(3, /* 5 entries */, 32768) = 144 lstat("/htdocs/.", {st_mode=S_IFDIR|S_ISUID|0750, st_size=52, ...}) = 0 stat("/etc/localtime", 0x7ffffaef12c0) = -1 ENOENT (No such file or directory) open("/etc/localtime", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) geteuid() = 6012 getegid() = 6012 open("/etc/group", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) futex(0x7f0c0d3b61e0, FUTEX_WAIT_PRIVATE, 2, NULL The process stays there until I kill it on the server. I can see from the trace that the process tries to access /etc/localtime, passwd and group. Of course those files are not present in my chroot environment and my understanding is, that using internal-sftp does not require those. I have found http://unix.stackexchange.com/questions/32882/sftp-server-on-rhel6-disconnec ts-on-ls, which is slightly comparable. I do not get disconnected and I am on Debian, but symptoms are the same. I am using PAM with libnss-mysql. Any help is welcome. Thanks Brian Rosenberger From alex at alemate.ru Tue Mar 18 19:36:12 2014 From: alex at alemate.ru (Alexander V Alekseev) Date: Tue, 18 Mar 2014 12:36:12 +0400 (MSK) Subject: Threading support in ssh-agent (up from 2012). In-Reply-To: References: Message-ID: Hi all again, Two years ago I proposed a patch to support multithreading in ssh-agent to speedup authorization against large number of hosts. The discussion ended with: On Wed, 21 Mar 2012, Damien Miller wrote: > On Tue, 20 Mar 2012, alex at alemate.ru wrote: > >> Is there any hope for threaded ssh-agent to be included in the >> main trunk? > > No, sorry - we have no desire to make any part of OpenSSH multithreaded, > especially something as sensitive as ssh-agent. > > We might consider an alternate design that used fork() if it were simple > enough, but I'd encourage you to hold off as I plan on refactoring some > of the agent code in the next release. What is your current opinion on the topic? Most of the code in ssh-agent.c has not changed, so my patch still works with minor changes. Will you accept threaded design now? Thank you, Alexander. From djm at mindrot.org Wed Mar 19 08:16:13 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 19 Mar 2014 08:16:13 +1100 (EST) Subject: internal-sftp stuck on 'ls' with chrootdirectory In-Reply-To: <009701cf41fb$c0d07f40$42717dc0$@brutex.de> References: <009701cf41fb$c0d07f40$42717dc0$@brutex.de> Message-ID: On Mon, 17 Mar 2014, Brian Rosenberger wrote: > Hi all, > > I am using Match directive and internal-sftp to chroot sftp users into their > directory. Connection and login works. I can change directories and put/get > files. Also logging of the internal sftp-process works (created a /dev/log > socket inside the chroot). As soon as I use the 'ls' command, nothing > happens and the the process gets stuck. Listing files does work as soon as I > remove the chrootdirectory directive. ... > I am using PAM with libnss-mysql. This is likely the problem - the chrooted process is probably trying to connect to your MySQL server and failing. You could either arrange for MySQL to listen at the path it is expecting inside the chroot or see if you can trick nss-mysql into giving up by creating a stale socket at the path it is expecting. The first approach would give you correct usernames for 'ls -l' at the cost of potentially exposing sensitive data inside the chroot. The latter loses usernames but keeps the chroot clean. (all assuming this is indeed the problem) -d From brian at brutex.de Wed Mar 19 18:25:31 2014 From: brian at brutex.de (Brian Rosenberger) Date: Wed, 19 Mar 2014 08:25:31 +0100 Subject: internal-sftp stuck on 'ls' with chrootdirectory In-Reply-To: References: <009701cf41fb$c0d07f40$42717dc0$@brutex.de> Message-ID: <00f601cf4344$691f4d90$3b5de8b0$@brutex.de> Hi Damien, Actually I am connecting mysql via IP, so I assume it is not the connection causing the problem, but maybe some dependencies issues. I have to say that on another linux box (same configuration but older debian version) the chroot setup including libnss-mysql does work. So I am missing something else here. Cheers Brian -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Dienstag, 18. M?rz 2014 22:16 To: Brian Rosenberger Cc: openssh-unix-dev at mindrot.org Subject: Re: internal-sftp stuck on 'ls' with chrootdirectory On Mon, 17 Mar 2014, Brian Rosenberger wrote: > Hi all, > > I am using Match directive and internal-sftp to chroot sftp users into > their directory. Connection and login works. I can change directories > and put/get files. Also logging of the internal sftp-process works > (created a /dev/log socket inside the chroot). As soon as I use the > 'ls' command, nothing happens and the the process gets stuck. Listing > files does work as soon as I remove the chrootdirectory directive. ... > I am using PAM with libnss-mysql. This is likely the problem - the chrooted process is probably trying to connect to your MySQL server and failing. You could either arrange for MySQL to listen at the path it is expecting inside the chroot or see if you can trick nss-mysql into giving up by creating a stale socket at the path it is expecting. The first approach would give you correct usernames for 'ls -l' at the cost of potentially exposing sensitive data inside the chroot. The latter loses usernames but keeps the chroot clean. (all assuming this is indeed the problem) -d From mancha1 at zoho.com Thu Mar 20 06:41:59 2014 From: mancha1 at zoho.com (mancha) Date: Wed, 19 Mar 2014 19:41:59 +0000 Subject: OpenSSH 6.6 (env vars) Message-ID: <20140319194159.GA25758@zoho.com> Hello. For the purposes of backporting, can you please confirm the relevant change for the environment variable security fix in 6.6 is: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c.diff?r1=1.270;r2=1.271 FYI, not sure if the request originated with OpenBSD/OpenSSH but this has been assigned CVE-2014-2532. Thanks. --mancha From keisial at gmail.com Thu Mar 20 07:48:04 2014 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Wed, 19 Mar 2014 21:48:04 +0100 Subject: Query on window adjust in SSH server In-Reply-To: References: Message-ID: <532A0284.9070101@gmail.com> On 17/03/14 05:55, abhilash abraham wrote: > Hi, > > I have a problem regarding window adjust, in the SSH server. > > I was trying to get a file of 400K from a system, via SFTP, which has old > version of openSSH [v2.0 or so] in it. I'm using Windows client, filezilla, > to get thre file. Once it reaches ~12k, the transfer gets halted. On > debugging I could find that it has reached the maximum window size in the > server and the client is never again sending the window adjust message. > > In RFC, I couldn't find anything about handling this situation. Can you > please let me know whether the server has the 'right' to adjust the window > size without the message from client. Or is there any reason for the client > not sending the adjust message[like its not aware of window exhausted in > server]? This looks like a TCP question, not a sshd one. Were you viewing the messages on client or server? Is it possible that frames go missing in the client-server communication? From keisial at gmail.com Thu Mar 20 07:46:09 2014 From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 19 Mar 2014 21:46:09 +0100 Subject: protocol error : expected control record In-Reply-To: References: Message-ID: <532A0211.2030605@gmail.com> On 17/03/14 11:48, RAVI PRATAP Singh wrote: > Hi All, > > During scp, I am seeing this message > protocol error : expected control record > > This message came because scp sink was expecting the message starting from > 'C' or 'D' , something like C0644 299 group or D0755 0 docs but during dns > query we were printing "Using IP address" message on the stdout. > > So , the message in the buffer was "Using IP address" and thus message > "protocol error : expected control record" was thrown. > > > Is openssh scp should always expect 'Cmmmm' or 'Dmmmm' messages ? Is fix > available for taking care scenario where on stdout something is printed. > > Thanks > Ravi Pratap That's a known drawback of scp, messages on stdout by other programs interfere with it. The ?solution? is to .use sftp instead. Anyway, you should only be printing that message on interactive sessions. Commands like: ssh myhost "cat /etc/passwd" > passwd-copy shouldn't be prefixed with the ip address you were using :) From nkadel at gmail.com Thu Mar 20 10:15:29 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 19 Mar 2014 19:15:29 -0400 Subject: protocol error : expected control record In-Reply-To: <532A0211.2030605@gmail.com> References: <532A0211.2030605@gmail.com> Message-ID: The "solution" is to use "rsync -e ssh", which is often far more efficient and idem potent. Nico Kadel-Garcia Email: nkadel at gmail.com Sent from iPhone > On Mar 19, 2014, at 16:46, ?ngel Gonz?lez wrote: > >> On 17/03/14 11:48, RAVI PRATAP Singh wrote: >> Hi All, >> >> During scp, I am seeing this message >> protocol error : expected control record >> >> This message came because scp sink was expecting the message starting from >> 'C' or 'D' , something like C0644 299 group or D0755 0 docs but during dns >> query we were printing "Using IP address" message on the stdout. >> >> So , the message in the buffer was "Using IP address" and thus message >> "protocol error : expected control record" was thrown. >> >> >> Is openssh scp should always expect 'Cmmmm' or 'Dmmmm' messages ? Is fix >> available for taking care scenario where on stdout something is printed. >> >> Thanks >> Ravi Pratap > > That's a known drawback of scp, messages on stdout by other programs interfere with it. The ?solution? is to .use sftp instead. > Anyway, you should only be printing that message on interactive sessions. > > Commands like: > ssh myhost "cat /etc/passwd" > passwd-copy > shouldn't be prefixed with the ip address you were using :) > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Thu Mar 20 14:25:27 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Mar 2014 14:25:27 +1100 (EST) Subject: OpenSSH 6.6 (env vars) In-Reply-To: <20140319194159.GA25758@zoho.com> References: <20140319194159.GA25758@zoho.com> Message-ID: On Wed, 19 Mar 2014, mancha wrote: > Hello. > > For the purposes of backporting, can you please confirm the relevant > change for the environment variable security fix in 6.6 is: > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c.diff?r1=1.270;r2=1.271 Only the first chunk of the diff is strictly needed, the rest is hygiene. > FYI, not sure if the request originated with OpenBSD/OpenSSH but this > has been assigned CVE-2014-2532. Sigh, another inaccurate OpenSSH CVE. "Authentication: Not required to exploit", -d From abhilashtabraham at gmail.com Thu Mar 20 14:41:00 2014 From: abhilashtabraham at gmail.com (abhilash abraham) Date: Thu, 20 Mar 2014 09:11:00 +0530 Subject: Query on window adjust in SSH server In-Reply-To: <532A0284.9070101@gmail.com> References: <532A0284.9070101@gmail.com> Message-ID: Hi Angel, Thanks for the reply. The message was seen in server. There is NO chance of frames to be missing. On Thu, Mar 20, 2014 at 2:18 AM, ?ngel Gonz?lez wrote: > On 17/03/14 05:55, abhilash abraham wrote: > >> Hi, >> >> I have a problem regarding window adjust, in the SSH server. >> >> I was trying to get a file of 400K from a system, via SFTP, which has >> old >> version of openSSH [v2.0 or so] in it. I'm using Windows client, >> filezilla, >> to get thre file. Once it reaches ~12k, the transfer gets halted. On >> debugging I could find that it has reached the maximum window size in the >> server and the client is never again sending the window adjust message. >> >> In RFC, I couldn't find anything about handling this situation. Can >> you >> please let me know whether the server has the 'right' to adjust the window >> size without the message from client. Or is there any reason for the >> client >> not sending the adjust message[like its not aware of window exhausted in >> server]? >> > This looks like a TCP question, not a sshd one. > Were you viewing the messages on client or server? Is it possible that > frames > go missing in the client-server communication? > > -- ?????????????? ??? From mancha1 at zoho.com Thu Mar 20 19:34:49 2014 From: mancha1 at zoho.com (mancha) Date: Thu, 20 Mar 2014 08:34:49 +0000 Subject: OpenSSH 6.6 (env vars) In-Reply-To: References: <20140319194159.GA25758@zoho.com> Message-ID: <20140320083449.GA1771@zoho.com> On Thu, Mar 20, 2014 at 02:25:27PM +1100, Damien Miller wrote: > Only the first chunk of the diff is strictly needed, the rest is hygiene. Great. thanks. > Sigh, another inaccurate OpenSSH CVE. "Authentication: Not required to > exploit", I was also suprised by the description. --mancha From keisial at gmail.com Fri Mar 21 06:10:47 2014 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Thu, 20 Mar 2014 20:10:47 +0100 Subject: Query on window adjust in SSH server In-Reply-To: References: <532A0284.9070101@gmail.com> Message-ID: <532B3D37.10305@gmail.com> On 20/03/14 04:41, abhilash abraham wrote: > Hi Angel, > > Thanks for the reply. > > The message was seen in server. There is NO chance of > frames to be missing. Ok, seems you need to debug on the client then. Start by confirming the client does see the window-full message but does not adjust it, and go up in the software stack seeing why the client is not reading the data. Regards From sduckwo at clemson.edu Fri Mar 21 06:58:25 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 20 Mar 2014 15:58:25 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin Message-ID: Hi all, I'm new to the list, so please forgive me if this is duplicated effort. I have created a patch for openssh which modifies the AuthorizedKeysCommand directive so that the incoming user's public key is sent to the specified program via stdin. This provides a means to identify the connecting user based solely on their public key and not just by the username. The inspiration for this was to be able to provide a service similar to GitHub or Bitbucket, where a user uploads their SSH public key(s) via a web interface and accesses their repositories over SSH using a common user account like "git" or "hg". However, there are likely many other use cases. The patches for different openssh versions can be found at https://bitbucket.org/ClemsonSoCUnix/django-sshkey. The README.md file describes some caveats, including the possibility for deadlock if the command specified with AuthorizedKeysCommand does not fully consume or close its standard input. I've been running the modified code in production with ~100 users on 6.2p2 for 7 months now with no known issues. I welcome any feedback on the patches. Scott From dkg at fifthhorseman.net Fri Mar 21 07:17:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Mar 2014 16:17:46 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: Message-ID: <532B4CEA.5080903@fifthhorseman.net> On 03/20/2014 03:58 PM, Scott Duckworth wrote: > I have created a patch for openssh which modifies the AuthorizedKeysCommand > directive so that the incoming user's public key is sent to the specified > program via stdin. This provides a means to identify the connecting user > based solely on their public key and not just by the username. This sounds like a good approach to me; you're not the first person to consider this, but i like the semantics of your proposal better than other proposals i've seen. Could you provide the patch against the mainline as an attachment to: https://bugzilla.mindrot.org/show_bug.cgi?id=2081 with a brief comment about how what you've done is different from what's there already? > The patches for different openssh versions can be found at > https://bitbucket.org/ClemsonSoCUnix/django-sshkey. The README.md file > describes some caveats, including the possibility for deadlock if the > command specified with AuthorizedKeysCommand does not fully consume or > close its standard input. This is worrisome. sshd itself shouldn't be adversely affected by subcommand failing to process the data in any way. Do you see any way to make sshd more robust in this case? (e.g. what if the key was provided as another command line parameter instead of stdin) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From abhilashtabraham at gmail.com Fri Mar 21 15:33:05 2014 From: abhilashtabraham at gmail.com (abhilash abraham) Date: Fri, 21 Mar 2014 10:03:05 +0530 Subject: Query on window adjust in SSH server In-Reply-To: <532B3D37.10305@gmail.com> References: <532A0284.9070101@gmail.com> <532B3D37.10305@gmail.com> Message-ID: Hi Angel, What do you mean by 'window-full message'? Is there any such message being sent from the server to the client? I didn't find it. Or which message from server is identified as the 'window-full' message? On Fri, Mar 21, 2014 at 12:40 AM, ?ngel Gonz?lez wrote: > On 20/03/14 04:41, abhilash abraham wrote: > > Hi Angel, > > Thanks for the reply. > > The message was seen in server. There is NO chance of > frames to be missing. > > > Ok, seems you need to debug on the client then. Start by confirming the > client does see the > window-full message but does not adjust it, and go up in the software > stack seeing why > the client is not reading the data. > > Regards > > -- ?????????????? ??? From mh+openssh-unix-dev at zugschlus.de Fri Mar 21 17:54:01 2014 From: mh+openssh-unix-dev at zugschlus.de (Marc Haber) Date: Fri, 21 Mar 2014 07:54:01 +0100 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: Message-ID: <20140321065401.GA21069@torres.zugschlus.de> On Thu, Mar 20, 2014 at 03:58:25PM -0400, Scott Duckworth wrote: > I have created a patch for openssh which modifies the AuthorizedKeysCommand > directive so that the incoming user's public key is sent to the specified > program via stdin. I would not do that in stdin as this precludes many standard commands from being used here. How about environment variables for key, fingerprint and probably comment? Wait, the ssh server doesn't know about a key's comment, does it? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 From mancha1 at zoho.com Fri Mar 21 17:53:45 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 21 Mar 2014 06:53:45 +0000 Subject: windigo post-mortem Message-ID: <20140321065345.GA11270@zoho.com> ESET recently published an interesting post-mortem of the so-called "Operation Windigo" malware campaign [1]. OpenSSH backdoors (codename Linux/Ebury), described by ESET last month [2], are a key component of Windigo's attack surface. --mancha [1] http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf [2] http://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/ From djm at mindrot.org Fri Mar 21 18:35:20 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Mar 2014 18:35:20 +1100 (EST) Subject: windigo post-mortem In-Reply-To: <20140321065345.GA11270@zoho.com> References: <20140321065345.GA11270@zoho.com> Message-ID: On Fri, 21 Mar 2014, mancha wrote: > ESET recently published an interesting post-mortem of the so-called > "Operation Windigo" malware campaign [1]. > > OpenSSH backdoors (codename Linux/Ebury), described by ESET last month > [2], are a key component of Windigo's attack surface. What is libkeyutils.so? Is it linked to by some vendor patch? AFAIK pristine OpenSSH never links to it. I saw a really early version of this trojan while helping with some forensics, but it was before it started hiding itself using libkeyutils.so... -d From dkg at fifthhorseman.net Sat Mar 22 00:49:21 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Mar 2014 09:49:21 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140321065401.GA21069@torres.zugschlus.de> References: <20140321065401.GA21069@torres.zugschlus.de> Message-ID: <532C4361.4090503@fifthhorseman.net> On 03/21/2014 02:54 AM, Marc Haber wrote: > I would not do that in stdin as this precludes many standard commands > from being used here. How about environment variables for key, > fingerprint and probably comment? If you have the key, you don't need the fingerprint. > Wait, the ssh server doesn't know about a key's comment, does it? the comment is irrelevant to the authorization process, since it's not explicitly bound to the key at all (try exiting the comment in either your id_rsa.pub or in .ssh/authorized_keys -- a mismatch has no effect). Given that, i think authorizedkeyscommand only needs access to the key. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From kevin.brott at gmail.com Sat Mar 22 00:51:50 2014 From: kevin.brott at gmail.com (Kevin Brott) Date: Fri, 21 Mar 2014 06:51:50 -0700 Subject: windigo post-mortem In-Reply-To: References: <20140321065345.GA11270@zoho.com> Message-ID: In Debian (7.4) this is what shows up for libkeyutils. I'm using built-from-source ssh so I can't check for usage, but I'll take a look once I'm in at work. Note the attribution though, guessing this is endemic in RH systems. $ apt-cache show libkeyutils1 Package: libkeyutils1 Source: keyutils Version: 1.5.5-3 Installed-Size: 19 Maintainer: Daniel Baumann Architecture: amd64 Depends: libc6 (>= 2.7) Pre-Depends: multiarch-support Description-en: Linux Key Management Utilities (library) Keyutils is a set of utilities for managing the key retention facility in the kernel, which can be used by filesystems, block devices and more to gain and retain the authorization and encryption keys required to perform secure operations. . This package provides a wrapper library for the key management facility system calls. Multi-Arch: same Homepage: http://people.redhat.com/~dhowells/keyutils/ On Fri, Mar 21, 2014 at 12:35 AM, Damien Miller wrote: > On Fri, 21 Mar 2014, mancha wrote: > > > ESET recently published an interesting post-mortem of the so-called > > "Operation Windigo" malware campaign [1]. > > > > OpenSSH backdoors (codename Linux/Ebury), described by ESET last month > > [2], are a key component of Windigo's attack surface. > > What is libkeyutils.so? Is it linked to by some vendor patch? AFAIK > pristine OpenSSH never links to it. > > I saw a really early version of this trojan while helping with some > forensics, but it was before it started hiding itself using > libkeyutils.so... > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- # include /* Kevin Brott */ From dkg at fifthhorseman.net Sat Mar 22 01:04:03 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Mar 2014 10:04:03 -0400 Subject: windigo post-mortem In-Reply-To: References: <20140321065345.GA11270@zoho.com> Message-ID: <871txvlkbw.fsf@alice.fifthhorseman.net> On Fri 2014-03-21 03:35:20 -0400, Damien Miller wrote: > What is libkeyutils.so? Is it linked to by some vendor patch? AFAIK > pristine OpenSSH never links to it. It's for the Linux kernel's stored-key API. From debian: Package: libkeyutils1 Source: keyutils Version: 1.5.6-1 Installed-Size: 20 Maintainer: Luk Claes Architecture: amd64 Depends: libc6 (>= 2.14) Pre-Depends: multiarch-support Description-en: Linux Key Management Utilities (library) Keyutils is a set of utilities for managing the key retention facility in the kernel, which can be used by filesystems, block devices and more to gain and retain the authorization and encryption keys required to perform secure operations. . This package provides a wrapper library for the key management facility system calls. Description-md5: 5c4d88a0a818e5ef897f2a9fa5c3ac2d Multi-Arch: same Homepage: http://people.redhat.com/~dhowells/keyutils/ Tag: implemented-in::c, role::shared-lib Section: libs Priority: standard Filename: pool/main/k/keyutils/libkeyutils1_1.5.6-1_amd64.deb Size: 8758 MD5sum: cec68a56387ef750ca89716761f59ed2 SHA1: fd7b6baa5aca294775ef8f9c51e65e003d641ed9 SHA256: b8f0d88776c44d59d30528d8ef81dba3a2519a53b71c8fe915a406f2e7a49bf1 It is a reverse dependency of libkrb5-3 and other k5 libraries, so it's brought in by the gssapi vendor patchset, i think. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From kevin.brott at gmail.com Sat Mar 22 01:48:11 2014 From: kevin.brott at gmail.com (Kevin Brott) Date: Fri, 21 Mar 2014 07:48:11 -0700 Subject: windigo post-mortem In-Reply-To: <871txvlkbw.fsf@alice.fifthhorseman.net> References: <20140321065345.GA11270@zoho.com> <871txvlkbw.fsf@alice.fifthhorseman.net> Message-ID: Confirmed - it appears to be linked into libgssapi_krb5.so and libkrb5.so, which in Debian is provided by libgssapi-krb5-2 and libkrb5-3, which are both direct dependency of the openssh-server package. The link chain goes like so sshd <- libkrb5.so <- libkeyutils.so It's in RHEL as far back at least 5.4 (while it exists in 4.6 it's not linked into ssh), keyutils-libs is a dependency of krb5-libs - so it's still an indirect dependency of the openssh-server package. On Fri, Mar 21, 2014 at 7:04 AM, Daniel Kahn Gillmor wrote: > On Fri 2014-03-21 03:35:20 -0400, Damien Miller wrote: > > What is libkeyutils.so? Is it linked to by some vendor patch? AFAIK > > pristine OpenSSH never links to it. > > It's for the Linux kernel's stored-key API. > > From debian: > > Package: libkeyutils1 > Source: keyutils > Version: 1.5.6-1 > Installed-Size: 20 > Maintainer: Luk Claes > Architecture: amd64 > Depends: libc6 (>= 2.14) > Pre-Depends: multiarch-support > Description-en: Linux Key Management Utilities (library) > Keyutils is a set of utilities for managing the key retention facility in > the > kernel, which can be used by filesystems, block devices and more to gain > and > retain the authorization and encryption keys required to perform secure > operations. > . > This package provides a wrapper library for the key management facility > system > calls. > Description-md5: 5c4d88a0a818e5ef897f2a9fa5c3ac2d > Multi-Arch: same > Homepage: http://people.redhat.com/~dhowells/keyutils/ > Tag: implemented-in::c, role::shared-lib > Section: libs > Priority: standard > Filename: pool/main/k/keyutils/libkeyutils1_1.5.6-1_amd64.deb > Size: 8758 > MD5sum: cec68a56387ef750ca89716761f59ed2 > SHA1: fd7b6baa5aca294775ef8f9c51e65e003d641ed9 > SHA256: b8f0d88776c44d59d30528d8ef81dba3a2519a53b71c8fe915a406f2e7a49bf1 > > It is a reverse dependency of libkrb5-3 and other k5 libraries, so it's > brought in by the gssapi vendor patchset, i think. > > hth, > > --dkg > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- # include /* Kevin Brott */ From sduckwo at clemson.edu Sat Mar 22 02:16:17 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 21 Mar 2014 11:16:17 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <532C4361.4090503@fifthhorseman.net> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> Message-ID: On Friday, March 21, 2014, Daniel Kahn Gillmor wrote: > > On 03/21/2014 02:54 AM, Marc Haber wrote: > > I would not do that in stdin as this precludes many standard commands > > from being used here. How about environment variables for key, > > fingerprint and probably comment? > > If you have the key, you don't need the fingerprint. > > Given that, i think authorizedkeyscommand only needs access to the key. The problem with passing the key in an environment variable is a potential for overflowing the available space?(see the "limits on size of arguments and environment" section on http://man7.org/linux/man-pages/man2/execve.2.html). ?Passing the fingerprint may be a better option. If there is a fingerprint collision then the AuthorizedKeysCommand can just print out all of them and leave it up to sshd to find the exact match, which it already does anyways. In my use case of this feature I'm already storing the fingerprints along with the keys in a database and my AuthorizedKeysCommand performs the lookup based only on the fingerprint. In other words, not having the full key would be fine. I realize this may not be the case for everybody but maybe it's good enough? From dkg at fifthhorseman.net Sat Mar 22 03:15:26 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Mar 2014 12:15:26 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> Message-ID: <532C659E.3010506@fifthhorseman.net> On 03/21/2014 11:16 AM, Scott Duckworth wrote: > The problem with passing the key in an environment variable is a > potential for overflowing the available space (see the "limits on size > of arguments and environment" section on > http://man7.org/linux/man-pages/man2/execve.2.html). those limits suggest that the size is 128kiB on anything resembling a modern Linux system. ssh-keygen doesn't generate anything greater than 16384 bits (16Kib, or 2KiB), and very few people use anything even close to that size. using base64 encoding inflates the size to 4/3, so we're talking about < 3KiB for the full base64-enoded, largest possible public key. More modern keys (EdDSA or ECDSA) are much much smaller. I'm glad you're thinking about size limits for env and argv, but i don't think this is even close to the size limits of realistic systems. That said, if you're still concerned, maybe there's a way to fix the deadlock case you raised and go back to the stdin approach? > Passing the > fingerprint may be a better option. If there is a fingerprint > collision then the AuthorizedKeysCommand can just print out all of > them and leave it up to sshd to find the exact match, which it already > does anyways. I see no need to rely on fingerprints when machines are doing key comparison. it introduces another point of cryptographic attack (the data structures and digest algorithm for the fingerprint mechanism itself), and saves very little. fingerprints are for humans. Also, with the full key available, it's possible for the authorizedkeyscommand to do other operations with the key itself (e.g. to evaluate the cryptographic parameters of the key itself, or to compute non-MD5-based forms of fingerprints, to compare the key material with other keys, etc) > In my use case of this feature I'm already storing the fingerprints > along with the keys in a database and my AuthorizedKeysCommand > performs the lookup based only on the fingerprint. In other words, not > having the full key would be fine. I realize this may not be the case > for everybody but maybe it's good enough? I think if we're going to make this change, the full key is the way to go. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From bowman at math.utah.edu Sat Mar 22 03:15:56 2014 From: bowman at math.utah.edu (Pieter Bowman) Date: Fri, 21 Mar 2014 10:15:56 -0600 (MDT) Subject: Bug? between OpenSSH 6.4p1 and 6.5p1(also 6.6p1) Message-ID: The problem I am seeing was introduced between 6.4p1 and 6.5p1 (and still exists in 6.6p1). With HostbasedAuthentication/EnableSSHKeysign turned on, I am seeing one of two sets of messages: no matching hostkey found ssh_keysign: no reply key_sign failed and not a valid request ssh_keysign: no reply key_sign failed Then in either case two password prompts: bowman at HOST.math.utah.edu's password: Permission denied, please try again. bowman at HOST.math.utah.edu's password: I've used strace and dtrace to watch what files are opened and executables run. All the correct key files are accessed and the correct version of ssh-keysign used. Even the ssh-keysign from 6.5p1 or 6.6p1 works correctly with ssh from 6.4p1. Various systems are affected by this: MacOS X 10.5/ppc OpenBSD 5.1/x86 RHEL 5/x86 Solaris 10/x86 Solaris 11/x64 Ubuntu 12.04/x86 debian 6.0/mips gentoo/alpha gentoo/ppc gentoo/ppc64 gentoo/sparc A few systems are not affected: IRIX 6.5/mips RHEL 5/ia64 Solaris 10/sparc Any ideas on where to look? Thanks, Pieter From esk-openssh at esk.cs.usu.edu Sat Mar 22 03:38:42 2014 From: esk-openssh at esk.cs.usu.edu (Eldon Koyle) Date: Fri, 21 Mar 2014 10:38:42 -0600 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <532B4CEA.5080903@fifthhorseman.net> References: <532B4CEA.5080903@fifthhorseman.net> Message-ID: <20140321163842.GB8684@esk.usu.edu> On Mar 20 16:17-0400, Daniel Kahn Gillmor wrote: > On 03/20/2014 03:58 PM, Scott Duckworth wrote: > > The patches for different openssh versions can be found at > > https://bitbucket.org/ClemsonSoCUnix/django-sshkey. The README.md file > > describes some caveats, including the possibility for deadlock if the > > command specified with AuthorizedKeysCommand does not fully consume or > > close its standard input. > > This is worrisome. sshd itself shouldn't be adversely affected by > subcommand failing to process the data in any way. Do you see any way > to make sshd more robust in this case? (e.g. what if the key was > provided as another command line parameter instead of stdin) Would it be reasonable to add another configuration option to specify that you want to send the key via stdin to the AuthorizedKeysCommand, and have it default to no/false? This should be enough to prevent breakage of existing implementations while still allowing the new and useful functionality. -- Eldon Koyle -- ... Logically incoherent, semantically incomprehensible, and legally ... impeccable! From dkg at fifthhorseman.net Sat Mar 22 03:50:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Mar 2014 12:50:44 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140321163842.GB8684@esk.usu.edu> References: <532B4CEA.5080903@fifthhorseman.net> <20140321163842.GB8684@esk.usu.edu> Message-ID: <532C6DE4.2030503@fifthhorseman.net> On 03/21/2014 12:38 PM, Eldon Koyle wrote: > Would it be reasonable to add another configuration option to specify > that you want to send the key via stdin to the AuthorizedKeysCommand, > and have it default to no/false? This should be enough to prevent > breakage of existing implementations while still allowing the new and > useful functionality. I think minimizing configuration options would be good -- extra knobs make it easier for admins to break things and harder for admins to get things to work. Are we sure this concern can't just be fixed in code? I don't understand why using stdin would necessarily result in a deadlock to the parent, but maybe i just haven't worked through the problem in enough depth. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From sduckwo at clemson.edu Sat Mar 22 04:52:10 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 21 Mar 2014 13:52:10 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <532C6DE4.2030503@fifthhorseman.net> References: <532B4CEA.5080903@fifthhorseman.net> <20140321163842.GB8684@esk.usu.edu> <532C6DE4.2030503@fifthhorseman.net> Message-ID: On Fri, Mar 21, 2014 at 12:50 PM, Daniel Kahn Gillmor wrote: > Are we sure this concern can't just be fixed in code? I don't > understand why using stdin would necessarily result in a deadlock to the > parent, but maybe i just haven't worked through the problem in enough depth. I haven't tried to produce the deadlock, but I think it's entirely possible when the incoming connection provides an extremely large public key (where the length of the base64 encoded keys is greater than the pipe size). The deadlock would be in key_write(), in the last call to fprintf() where the key type name and the base64 encoded key is printed to the FILE * that was passed to key_write(). It would deadlock because it's trying to write to a pipe that's never being read from. The pipe itself would buffer some unread data (how much varies by OS - I get 16KiB by default on Linux), and the FILE buffered I/O layer adds a little extra (I get a few hundred extra bytes on Linux/glibc). If the key size is greater than that then there's a deadlock. My first thought to fix this would be to put a timeout on this write, but that seems a little hackish and how that could best be accomplished is not immediately clear to me. I'm also now realizing that I haven't tested a AuthorizedKeysCommand that does close stdin, and I'm concerned that it would send a SIGPIPE to the writer and I'm not sure how that signal is handled in sshd. Maybe putting the write behind a select() or poll() could handle the timeout as well as detecting when the pipe is closed. After seeing all of this I am also in favor of environment variables. It seems like it would be cleaner and require fewer changes. From sduckwo at clemson.edu Sat Mar 22 04:56:36 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 21 Mar 2014 13:56:36 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <532C659E.3010506@fifthhorseman.net> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> Message-ID: On Fri, Mar 21, 2014 at 12:15 PM, Daniel Kahn Gillmor wrote: > those limits suggest that the size is 128kiB on anything resembling a > modern Linux system. How about other platforms? > ssh-keygen doesn't generate anything greater than 16384 bits (16Kib, or > 2KiB), and very few people use anything even close to that size. using > base64 encoding inflates the size to 4/3, so we're talking about < 3KiB > for the full base64-enoded, largest possible public key. > > More modern keys (EdDSA or ECDSA) are much much smaller. > > I'm glad you're thinking about size limits for env and argv, but i don't > think this is even close to the size limits of realistic systems. Even though ssh-keygen doesn't produce anything larger than 16384 bits, wouldn't it be possible for somebody to craft a key that is larger to attempt a buffer overflow? From keisial at gmail.com Sat Mar 22 09:45:38 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 21 Mar 2014 23:45:38 +0100 Subject: Bug? between OpenSSH 6.4p1 and 6.5p1(also 6.6p1) In-Reply-To: References: Message-ID: <532CC112.40008@gmail.com> On 21/03/14 17:15, Pieter Bowman wrote: > Any ideas on where to look? Have you tried mixing the client sshs too? I would also try to log the contents passed to ssh-keysign (it will be binary data, but if for instance with the wrong version got a few bytes less, I would suspect the signature is being truncated by sshd) From esk-openssh at esk.cs.usu.edu Sat Mar 22 10:59:13 2014 From: esk-openssh at esk.cs.usu.edu (Eldon Koyle) Date: Fri, 21 Mar 2014 17:59:13 -0600 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> Message-ID: <20140321235913.GC8684@esk.usu.edu> On Mar 21 13:56-0400, Scott Duckworth wrote: > On Fri, Mar 21, 2014 at 12:15 PM, Daniel Kahn Gillmor > wrote: > > those limits suggest that the size is 128kiB on anything resembling a > > modern Linux system. > > How about other platforms? It looks like they are all over the place. See: http://www.in-ulm.de/~mascheck/various/argmax/#results for some actual numbers (however a lot of those seem to be pretty obscure *NIX variants). > > ssh-keygen doesn't generate anything greater than 16384 bits (16Kib, or > > 2KiB), and very few people use anything even close to that size. using > > base64 encoding inflates the size to 4/3, so we're talking about < 3KiB > > for the full base64-enoded, largest possible public key. > > > > More modern keys (EdDSA or ECDSA) are much much smaller. > > > > I'm glad you're thinking about size limits for env and argv, but i don't > > think this is even close to the size limits of realistic systems. > > Even though ssh-keygen doesn't produce anything larger than 16384 bits, > wouldn't it be possible for somebody to craft a key that is larger to > attempt a buffer overflow? You can check sysconf(_SC_ARG_MAX) to get an idea of the size limit. See: http://www.in-ulm.de/~mascheck/various/argmax/ for more detailed information. Also, setenv/putenv should return an error rather than overflow the buffer if the variable is too large. The only other concern would be a buffer overflow in the AuthorizedKeysCommand. See: https://www.owasp.org/index.php/Buffer_Overflow_via_Environment_Variables for an example. -- Eldon Koyle From lists at spuddy.org Sat Mar 22 11:39:15 2014 From: lists at spuddy.org (Stephen Harris) Date: Fri, 21 Mar 2014 20:39:15 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140321235913.GC8684@esk.usu.edu> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> Message-ID: <20140322003915.GA26432@mercury.spuddy.org> On Fri, Mar 21, 2014 at 05:59:13PM -0600, Eldon Koyle wrote: > Also, setenv/putenv should return an error rather than overflow the > buffer if the variable is too large. I'm jumping in here, just because it's the last message in the thread that I've received so far. I'm not sure if this patch is solving a problem that really exists. What's wrong with command="/path/to/command user1" ssh-dss key1... command="/path/to/command user2" ssh-dss key2... command="/path/to/command user3" ssh-dss key3... I've been doing that for years. If there is a problem then here's two alternatives... If we _do_ want to allow the key to be passed, why not pass the signature rather than the key? If we actually want the real key then do something similar to agent forwarding; put the used key into a (secure) temporary file and pass the filename in an environment variable. After the child process has exited then clean up the temporary file. Just like agent forwarding. In this case control it by another config file setting ("PassSSHkeyToSession yes") so we don't write files for no good reason. -- rgds Stephen From imorgan at nas.nasa.gov Sat Mar 22 11:53:15 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 21 Mar 2014 17:53:15 -0700 Subject: Bug? between OpenSSH 6.4p1 and 6.5p1(also 6.6p1) In-Reply-To: References: Message-ID: <20140322005314.GC28845@linux124.nas.nasa.gov> On Fri, Mar 21, 2014 at 10:15:56 -0600, Pieter Bowman wrote: > The problem I am seeing was introduced between 6.4p1 and 6.5p1 (and > still exists in 6.6p1). With HostbasedAuthentication/EnableSSHKeysign > turned on, I am seeing one of two sets of messages: > > no matching hostkey found > ssh_keysign: no reply > key_sign failed > > and > > not a valid request > ssh_keysign: no reply > key_sign failed > > > Then in either case two password prompts: > > bowman at HOST.math.utah.edu's password: > Permission denied, please try again. > bowman at HOST.math.utah.edu's password: > > > I've used strace and dtrace to watch what files are opened and > executables run. All the correct key files are accessed and the > correct version of ssh-keysign used. Even the ssh-keysign from 6.5p1 > or 6.6p1 works correctly with ssh from 6.4p1. > The ssh -vvv output might be of a little interest. I'm particularly curious as to whether you get the messages that you quoted with each keysign request or just the one for the ed25519 key. The behavour sounds like there is a version mismatch which is causing it to choke on the ed25519 key. You indicate that the correct ssh-keysign is being invoked, or at least the right path is used. Try running strings on the executable and grep for ed25519. Were yyou deliberately failing the two password prompts, or is that anouther aspect of the problem? -- Iain Morgan From jau789 at gmail.com Sat Mar 22 20:33:56 2014 From: jau789 at gmail.com (Jukka Ukkonen) Date: Sat, 22 Mar 2014 11:33:56 +0200 Subject: SCTP support for the common openssh source? Message-ID: <532D5904.1070101@gmail.com> Greetings, Are there any plans to import SCTP support to OpenSSH? There have been SCTP patches for OSX and FreeBSD, and those seem to work pretty decently. I guess there might quite a number of potential users for SCTP were it part of the common source tree. A second benefit of having SCTP support as a standard feature in OpenSSH for all platforms supporting SCTP would be kind of social pressure for more and more platforms to aim at adopting SCTP. Cheers, --jau From opensshdev at r.paypc.com Sat Mar 22 21:50:35 2014 From: opensshdev at r.paypc.com (Morham) Date: Sat, 22 Mar 2014 03:50:35 -0700 Subject: SCTP support for the common openssh source? In-Reply-To: <532D5904.1070101@gmail.com> References: <532D5904.1070101@gmail.com> Message-ID: <532D6AFB.2010109@r.paypc.com> > A second benefit of having SCTP support as a standard > feature in OpenSSH for all platforms supporting SCTP would > be kind of social pressure for more and more platforms to > aim at adopting SCTP. What is the benefit to this? =M= From Michael.Tuexen at lurchi.franken.de Sat Mar 22 21:48:43 2014 From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen) Date: Sat, 22 Mar 2014 11:48:43 +0100 Subject: SCTP support for the common openssh source? In-Reply-To: <532D5904.1070101@gmail.com> References: <532D5904.1070101@gmail.com> Message-ID: <857C7E82-E909-4F35-A39D-428A0D99D1E7@lurchi.franken.de> On 22 Mar 2014, at 10:33, Jukka Ukkonen wrote: > > Greetings, > > Are there any plans to import SCTP support to OpenSSH? > There have been SCTP patches for OSX and FreeBSD, and > those seem to work pretty decently. I guess there might > quite a number of potential users for SCTP were it part of > the common source tree. Depending of the level of SCTP support you want to integrate, the patches should also work on Linux, which also supports SCTP. Best regards Michael > A second benefit of having SCTP support as a standard > feature in OpenSSH for all platforms supporting SCTP would > be kind of social pressure for more and more platforms to > aim at adopting SCTP. > > Cheers, > --jau > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From bdrewery at FreeBSD.org Sun Mar 23 01:35:27 2014 From: bdrewery at FreeBSD.org (Bryan Drewery) Date: Sat, 22 Mar 2014 09:35:27 -0500 Subject: SCTP support for the common openssh source? In-Reply-To: <532D5904.1070101@gmail.com> References: <532D5904.1070101@gmail.com> Message-ID: <532D9FAF.60608@FreeBSD.org> On 3/22/2014 4:33 AM, Jukka Ukkonen wrote: > > Greetings, > > Are there any plans to import SCTP support to OpenSSH? > There have been SCTP patches for OSX and FreeBSD, and > those seem to work pretty decently. I guess there might > quite a number of potential users for SCTP were it part of > the common source tree. > A second benefit of having SCTP support as a standard > feature in OpenSSH for all platforms supporting SCTP would > be kind of social pressure for more and more platforms to > aim at adopting SCTP. > > Cheers, > --jau > FYI FreeBSD uses the patch from https://bugzilla.mindrot.org/show_bug.cgi?id=2016 It does not currently apply cleanly to 6.6p1 though. I did some tweaks to get the security/openssh-portable port to compile, but have not tested it. It would be great if it were upstreamed. -- Regards, Bryan Drewery -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Mar 23 03:05:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 22 Mar 2014 12:05:46 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140321235913.GC8684@esk.usu.edu> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> Message-ID: <532DB4DA.8000100@fifthhorseman.net> On 03/21/2014 07:59 PM, Eldon Koyle wrote: > It looks like they are all over the place. See: > http://www.in-ulm.de/~mascheck/various/argmax/#results > for some actual numbers (however a lot of those seem to be pretty > obscure *NIX variants). nice find. With the exception of a few operating systems from the 1970s (on which OpenSSH is unlikely to run anyway), those are all at least 5KiB, which is about double the largest possible key size generated by OpenSSH's ssh-keygen. > You can check sysconf(_SC_ARG_MAX) to get an idea of the size limit. > See: > http://www.in-ulm.de/~mascheck/various/argmax/ > for more detailed information. > > Also, setenv/putenv should return an error rather than overflow the > buffer if the variable is too large. similarly, exec should fail with E2BIG if the data is too large. So this is testable at runtime, when the peer sends a large key; in the event that the variable is too large, AuthorizedKeysCommand would simply fail closed. I think this is reasonable. We could also deliberately constrain the key size, and decline to execute AuthorizedKeysCommand (or execute it without passing any key as an environment variable or argument) if the client's proposed key is larger than the largest key generated by ssh-keygen (16Kib at the moment). This strikes me as a reasonable limit. > The only other concern would be a buffer overflow in the > AuthorizedKeysCommand. See: > https://www.owasp.org/index.php/Buffer_Overflow_via_Environment_Variables > for an example. sure, but this is a risk whether the data comes in via environment variables or stdin or argv or a local file, right? Given the discussion, i'm still leaning toward either an environment variable or argv. given that we're already using argv for the username, i think a second argv parameter would be the cleanest. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From sduckwo at clemson.edu Sun Mar 23 05:25:44 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Sat, 22 Mar 2014 14:25:44 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <532DB4DA.8000100@fifthhorseman.net> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> <532DB4DA.8000100@fifthhorseman.net> Message-ID: On Sat, Mar 22, 2014 at 12:05 PM, Daniel Kahn Gillmor wrote: > > You can check sysconf(_SC_ARG_MAX) to get an idea of the size limit. > > See: > > http://www.in-ulm.de/~mascheck/various/argmax/ > > for more detailed information. > > > > Also, setenv/putenv should return an error rather than overflow the > > buffer if the variable is too large. > > similarly, exec should fail with E2BIG if the data is too large. I ran some tests and it looks like setenv does not return an error when this happens but exec does (tested on Linux and Mac OS X). > So this is testable at runtime, when the peer sends a large key; in the > event that the variable is too large, AuthorizedKeysCommand would simply > fail closed. I think this is reasonable. Agreed. > We could also deliberately constrain the key size, and decline to > execute AuthorizedKeysCommand (or execute it without passing any key as > an environment variable or argument) if the client's proposed key is > larger than the largest key generated by ssh-keygen (16Kib at the > moment). This strikes me as a reasonable limit. If exec is catching the error for us then I don't see a need to impose another constraint on it that will have to be maintained. > Given the discussion, i'm still leaning toward either an environment > variable or argv. given that we're already using argv for the username, > i think a second argv parameter would be the cleanest. If compatibility with programs that expect exactly one command line parameter (the username) then it seems like the environment variable is the way to go. But I'll leave that decision up to those more involved with the development of openssh. From sduckwo at clemson.edu Sun Mar 23 05:38:32 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Sat, 22 Mar 2014 14:38:32 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140322003915.GA26432@mercury.spuddy.org> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> <20140322003915.GA26432@mercury.spuddy.org> Message-ID: On Fri, Mar 21, 2014 at 8:39 PM, Stephen Harris wrote: > I'm jumping in here, just because it's the last message in the thread > that I've received so far. > > I'm not sure if this patch is solving a problem that really exists. > > What's wrong with > command="/path/to/command user1" ssh-dss key1... > command="/path/to/command user2" ssh-dss key2... > command="/path/to/command user3" ssh-dss key3... > I've been doing that for years. The problem is more a problem of performance and scalability rather than functionality. Specifying the command in the keys, as you demonstrated, is still required to identify the user that owns the key. This is regardless of whether it comes from AuthorizedKeysCommand or AuthorizedKeysFile. But that's just a flat file stream, and sshd has to scan through every one to find the first match. When you're dealing with thousands or millions of keys (I'm not doing this, but places like GitHub are), that linear search becomes an issue. Being able to know what key is coming in enables one to perform a database lookup, which can be indexed, and is therefore much faster and much more scalable. > If there is a problem then here's two alternatives... > > If we _do_ want to allow the key to be passed, why not pass the signature > rather than the key? Passing only the fingerprint was something we discussed earlier in the thread. It would still work for some use cases, but instead of returning only the exact match(es) to sshd it would return those that match the fingerprint (which might have collisions). In this case sshd would still be dealing with a small subset of all keys and would find the first key that does exactly match. > If we actually want the real key then do something similar to agent > forwarding; put the used key into a (secure) temporary file and pass the > filename in an environment variable. After the child process has exited > then clean up the temporary file. Just like agent forwarding. In this > case control it by another config file setting ("PassSSHkeyToSession yes") > so we don't write files for no good reason. That seems to be overkill for public keys. From solo-openssh at goeswhere.com Sun Mar 23 05:43:49 2014 From: solo-openssh at goeswhere.com (solo-openssh at goeswhere.com) Date: Sat, 22 Mar 2014 18:43:49 +0000 Subject: ProxyCommand's argument escaping Message-ID: <20140322184348.GA19540@goeswhere.com> When using a ProxyCommand, it appears that the arguments to it are passed in an unsafe manner: % ssh -o ProxyCommand='nc %h %p' '$(not found)' zsh:1: command not found: not nc: you must specify the address/port couple of the remote endpoint ssh_exchange_identification: Connection closed by remote host This is not zsh specific (e.g. it happens with bash). One can resolve the immediate problem (which it turned out wasn't even the problem I was thinking of!) by attempting to quote %h: % ssh -o ProxyCommand='nc '\''%h'\'' %p' '$(not found)' nc: forward host lookup failed for remote endpoint $(not found): Name or service not known .. but obviously this will fail if someone is motivated: % ssh -o ProxyCommand='nc '\''%h'\'' %p' \''$(not found)'\' This doesn't seem ideal, but is probably not an issue in practice. Maybe it allows motivated users who have permission to run ssh as other users to execute code as them? Badly configured sudo rsync backup jobs? I noticed attempting to use an IPv6 literal with its surrounding square-brackets ([::1]), which isn't allowed anyway, and my zsh config rejects due to `setopt nomatch`. From dkg at fifthhorseman.net Sun Mar 23 08:22:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 22 Mar 2014 17:22:44 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> <532DB4DA.8000100@fifthhorseman.net> Message-ID: <532DFF24.4000406@fifthhorseman.net> On 03/22/2014 02:25 PM, Scott Duckworth wrote: > If compatibility with programs that expect exactly one command line > parameter (the username) then it seems like the environment variable is the > way to go. But I'll leave that decision up to those more involved with the > development of openssh. After thinking about this a little more, i agree with you that the environment variable is the way to go, but for another reason. Many common operating systems expose each process' command line arguments to other processes on the system, regardless of effective userid, but they hide the environment from any other non-privileged users. Using an environment variable would avoid leaking the proposed public key to local users snooping around the process table. Thanks for the thoughtful and thorough discussion on this! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From lists at eitanadler.com Sun Mar 23 16:38:35 2014 From: lists at eitanadler.com (Eitan Adler) Date: Sat, 22 Mar 2014 22:38:35 -0700 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> Message-ID: On 21 March 2014 10:56, Scott Duckworth wrote: > On Fri, Mar 21, 2014 at 12:15 PM, Daniel Kahn Gillmor > wrote: >> those limits suggest that the size is 128kiB on anything resembling a >> modern Linux system. > > How about other platforms? Especially embedded systems which may have a lot less RAM? -- Eitan Adler From jau789 at gmail.com Sun Mar 23 19:13:42 2014 From: jau789 at gmail.com (Jukka Ukkonen) Date: Sun, 23 Mar 2014 10:13:42 +0200 Subject: SCTP support for the common openssh source? In-Reply-To: <532D9FAF.60608@FreeBSD.org> References: <532D5904.1070101@gmail.com> <532D9FAF.60608@FreeBSD.org> Message-ID: <532E97B6.10500@gmail.com> On 03/22/14 16:35, Bryan Drewery wrote: > FYI FreeBSD uses the patch from > https://bugzilla.mindrot.org/show_bug.cgi?id=2016 It does not > currently apply cleanly to 6.6p1 though. I did some tweaks to get the > security/openssh-portable port to compile, but have not tested it. It > would be great if it were upstreamed. In fact I ported the 5.6p1 patch to 6.6p1 on OSX 10.9.2 Maverics the other day. It needed a few changes, but AFAIK it now works just fine. Were SCTP support adopted as part of the upstream, the code might remain in shape far better. The separate patches tend to end up out of sync with the latest versions in the common code base when the code evolves from release to release. --jau From peter at stuge.se Sun Mar 23 19:59:40 2014 From: peter at stuge.se (Peter Stuge) Date: Sun, 23 Mar 2014 09:59:40 +0100 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> Message-ID: <20140323085940.2072.qmail@stuge.se> Eitan Adler wrote: > >> those limits suggest that the size is 128kiB on anything resembling a > >> modern Linux system. > > > > How about other platforms? > > Especially embedded systems which may have a lot less RAM? What's the problem with forking and writing to the pipe from the parent only when it is writable? //Peter From igor at mir2.org Sun Mar 23 20:45:14 2014 From: igor at mir2.org (Igor Bukanov) Date: Sun, 23 Mar 2014 10:45:14 +0100 Subject: ProxyCommand as both a resolver and connector Message-ID: I see that the hostname canonicalization configuration options is still rather limited. As that works on DNS level they are of not use if one has to use ProxyCommand to connect over a proxy connection or through a common gateway name where one uses different port numbers to connect to different intranet names. What would be ideal is to extend the ProxyCommand to both return the resolved universal name for the given short name and to connect to that universal name. For example, the proxy can first print the resolved name on its stdout before proceeding with other data. From sduckwo at clemson.edu Mon Mar 24 08:27:27 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Sun, 23 Mar 2014 17:27:27 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <532DFF24.4000406@fifthhorseman.net> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> <532DB4DA.8000100@fifthhorseman.net> <532DFF24.4000406@fifthhorseman.net> Message-ID: On Sat, Mar 22, 2014 at 5:22 PM, Daniel Kahn Gillmor wrote: > After thinking about this a little more, i agree with you that the > environment variable is the way to go, but for another reason. A patch to 6.6p1 to pass the key and fingerprint via environment variables SSH_KEY and SSH_KEY_FINGERPRINT, respectively, is at https://github.com/ScottDuckworth/openssh-akcenv. I can work on creating a patch against master and post it to the bug that you referenced in your first response to me. From keisial at gmail.com Mon Mar 24 09:28:46 2014 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Sun, 23 Mar 2014 23:28:46 +0100 Subject: Query on window adjust in SSH server In-Reply-To: References: <532A0284.9070101@gmail.com> <532B3D37.10305@gmail.com> Message-ID: <532F601E.3060506@gmail.com> On 21/03/14 05:33, abhilash abraham wrote: > Hi Angel, > > What do you mean by 'window-full message'? Is there any > such message being sent from the server to the client? I didn't find > it. Or which message from server is identified as the 'window-full' > message? Sorry for the ambiguity. The message filling the window size. There's not an explicit tcp message for that. From keisial at gmail.com Mon Mar 24 10:12:22 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 24 Mar 2014 00:12:22 +0100 Subject: [PATCH] [channels.c] Remove wrong channel_new() comment Message-ID: <532F6A56.7060208@gmail.com> channel_new() doesn't free remote_name since 2003/05/11 20:30:25 (git commit b1ca8bb) --- ChangeLog | 4 ++++ channels.c | 3 +-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4e6b8b2..8f203aa 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +20140323 + - [channels.c] Remove wrong channel_new() comment + channel_new doesn't free remote_name since 2003/05/11 20:30:25 + 20140317 - (djm) [sandbox-seccomp-filter.c] Soft-fail stat() syscalls. Add XXX to remind myself to add sandbox violation logging via the log socket. diff --git a/channels.c b/channels.c index 9efe89c..72f166d 100644 --- a/channels.c +++ b/channels.c @@ -265,8 +265,7 @@ channel_register_fds(Channel *c, int rfd, int wfd, int efd, } /* - * Allocate a new channel object and set its type and socket. This will cause - * remote_name to be freed. + * Allocate a new channel object and set its type and socket. */ Channel * channel_new(char *ctype, int type, int rfd, int wfd, int efd, -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Parte del mensaje adjunto URL: From sduckwo at clemson.edu Tue Mar 25 01:32:31 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Mon, 24 Mar 2014 10:32:31 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140321235913.GC8684@esk.usu.edu> <532DB4DA.8000100@fifthhorseman.net> <532DFF24.4000406@fifthhorseman.net> Message-ID: On Sun, Mar 23, 2014 at 5:27 PM, Scott Duckworth wrote: > I can work on creating a patch against master and post it to the bug that you referenced in your first response to me. I've attached the patch against cvs to https://bugzilla.mindrot.org/show_bug.cgi?id=2081#c5. The patch also includes documentation about the new feature to the sshd_config man page. From sduckwo at clemson.edu Tue Mar 25 01:42:33 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Mon, 24 Mar 2014 10:42:33 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140323085940.2072.qmail@stuge.se> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140323085940.2072.qmail@stuge.se> Message-ID: On Sun, Mar 23, 2014 at 4:59 AM, Peter Stuge wrote: > What's the problem with forking and writing to the pipe from the > parent only when it is writable? If the child process does not explicitly close stdin then there is no way to know if it is actually being read from. All that is known is that you can write *some* data to the pipe, but once the pipe's buffer fills up and it is not emptied then the parent process (sshd) will block indefinitely. The only way this could be avoided is by introducing some sort of timeout to the write. Polling to see when you can write without blocking won't be enough because the child process may just be slow to read the pipe, or it may have stopped reading before EOF. The only safe way to pass the key via a pipe is to require any AuthorizedKeysCommand to either explicitly close stdin or consume stdin until EOF. There's no way to enforce this in code, and there's likely already a lot of commands in use that do neither of these. Hence passing the data in environment variables or parameters are the only safe ways to do this. From mstone at mathom.us Tue Mar 25 02:39:50 2014 From: mstone at mathom.us (Michael Stone) Date: Mon, 24 Mar 2014 11:39:50 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140323085940.2072.qmail@stuge.se> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140323085940.2072.qmail@stuge.se> Message-ID: <20140324153950.GB17568@mathom.us> On Sun, Mar 23, 2014 at 09:59:40AM +0100, Peter Stuge wrote: >Eitan Adler wrote: >> Especially embedded systems which may have a lot less RAM? > >What's the problem with forking and writing to the pipe from the >parent only when it is writable? Is forking and keeping a process around (potentially forever?) really more RAM-friendly than a slight increase in the size of the environment? Mike Stone From peter at stuge.se Tue Mar 25 03:23:55 2014 From: peter at stuge.se (Peter Stuge) Date: Mon, 24 Mar 2014 17:23:55 +0100 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140323085940.2072.qmail@stuge.se> Message-ID: <20140324162355.6962.qmail@stuge.se> Scott Duckworth wrote: > > What's the problem with forking and writing to the pipe from the > > parent only when it is writable? > > If the child process does not explicitly close stdin then there is no way > to know if it is actually being read from. All that is known is that you > can write *some* data to the pipe, Right, as I wrote, write only when writable. > but once the pipe's buffer fills up and it is not emptied then ..it will no longer be writable. Does the last write() before buffers are full return short? If not, only write() a single byte at a time. I still do not see the problem here. > timeout A timeout within any general purpose OS is a heuristic, I don't think they belong in the authentication path. > The only safe way to pass the key via a pipe is to require any > AuthorizedKeysCommand to either explicitly close stdin or consume stdin > until EOF. I don't see why. > there's likely already a lot of commands in use that do neither of these. So maybe the new semantics deserve a new configuration option, rather than extending an existing option in a not-so-scalable way? //Peter From dkg at fifthhorseman.net Tue Mar 25 03:46:25 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Mar 2014 12:46:25 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140324162355.6962.qmail@stuge.se> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140323085940.2072.qmail@stuge.se> <20140324162355.6962.qmail@stuge.se> Message-ID: <53306161.3040802@fifthhorseman.net> On 03/24/2014 12:23 PM, Peter Stuge wrote: > So maybe the new semantics deserve a new configuration option, rather > than extending an existing option in a not-so-scalable way? Why is providing the key as an environment variable to the AuthorizedKeysCommand not-so-scalable? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From esk-openssh at esk.cs.usu.edu Tue Mar 25 05:18:18 2014 From: esk-openssh at esk.cs.usu.edu (Eldon Koyle) Date: Mon, 24 Mar 2014 12:18:18 -0600 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140324162355.6962.qmail@stuge.se> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140323085940.2072.qmail@stuge.se> <20140324162355.6962.qmail@stuge.se> Message-ID: <20140324181818.GD8684@esk.usu.edu> On Mar 24 17:23+0100, Peter Stuge wrote: > Scott Duckworth wrote: > > but once the pipe's buffer fills up and it is not emptied then > > ..it will no longer be writable. Does the last write() before buffers > are full return short? If not, only write() a single byte at a time. > > I still do not see the problem here. The default behavior is for the last write() to block until the buffer empties. You could possibly open the pipe with O_NONBLOCK (not sure how universal the support for this is), however I think the environment variable is the more friendly way to handle this. Writing to stdin, do you just give up if it would block? What if the process was just busy and still needs to read the key? Add some kind of timeout? > > timeout > > A timeout within any general purpose OS is a heuristic, I don't think > they belong in the authentication path. Does sshd fork before it handles a client authentication request? If so, the blocking is more or less a non-issue, as it will not block other authentication attempts. If the AuthorizedKeysCommand runs normally, it will exit and close the pipe. This only becomes an issue if the command hangs forever, which it would likely do with or without a pipe. What currently happens if an AuthorizedKeysCommand hangs? > > there's likely already a lot of commands in use that do neither of these. > > So maybe the new semantics deserve a new configuration option, rather > than extending an existing option in a not-so-scalable way? I think the environment variable is cleaner and easier than adding a new configuration option or trying to handle a full pipe. I suspect that there aren't very many operating systems that currently run openssh that would be affected here, and I also suspect that any OS with such tight memory requirements would opt to run something more like dropbear than openssh. -- Eldon Koyle -- BOFH excuse #355: Boredom in the Kernel. From sduckwo at clemson.edu Tue Mar 25 05:14:43 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Mon, 24 Mar 2014 14:14:43 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140324162355.6962.qmail@stuge.se> References: <20140321065401.GA21069@torres.zugschlus.de> <532C4361.4090503@fifthhorseman.net> <532C659E.3010506@fifthhorseman.net> <20140323085940.2072.qmail@stuge.se> <20140324162355.6962.qmail@stuge.se> Message-ID: On Mon, Mar 24, 2014 at 12:23 PM, Peter Stuge wrote: > ..it will no longer be writable. Does the last write() before buffers > are full return short? If not, only write() a single byte at a time. > > I still do not see the problem here. I've demonstrated how deadlock can occur in this situation at https://gist.github.com/ScottDuckworth/9745307 When acting on a blocking file descriptor, a write() (or fprintf() in this case) will block until either 1) all requested data is written or 2) there is some sort of signal. It will not "return short" if the pipe's buffer is full, it will simply wait until it has free space in the buffer and repeat until all data is written. It would be possible to set the pipe to non-blocking mode so that the fprintf() in key_write() will give up and return when the pipe's buffer is full instead of blocking. But in this case there is no way to distinguish between when that pipe will not be read from and a pipe that is just being read from slowly. If it's just slow, we still would want to write the entire key, and this would prevent that from happening. Writing a single byte at a time would not help the situation. In blocking mode there will eventually be one byte that blocks, and in non-blocking mode you'll still not know if the pipe is no longer being read from or if it's just being read from slowly. > A timeout within any general purpose OS is a heuristic, I don't think > they belong in the authentication path. I agree that a timeout does not belong here, but if communication were to be done using pipes it would be the only way to avoid deadlock. Hence the reason why it's best to avoid using pipes for bi-directional communication in this case. > So maybe the new semantics deserve a new configuration option, rather > than extending an existing option in a not-so-scalable way? I agree with Daniel in that I don't see how the environment variable method is not scalable enough for this scenario. From mikep at noc.utoronto.ca Wed Mar 26 02:17:23 2014 From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca) Date: Tue, 25 Mar 2014 11:17:23 -0400 (EDT) Subject: openssh-6.6p1 on Solaris 10 - 'make tests' fails, sshd won't start Message-ID: Openssh-6.6p1 compiled on Solaris 10, but failed the 'make tests' in the 'sftp' testing: failed sftp permissions make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/opt/local/src/security/openssh-6.6p1/regress' make: *** [tests] Error 2 [There are also a lot of 'Unsupported query "cipher-auth"' messages, which would indicate the tests are using the installed version of 'ssh' (which doesn't have 'ssh -Q cipher-auth') instead of the newly build version (which does have it).] After a 'make install', the new 'sshd' would not start: ld.so.1: sshd: fatal: relocation error: file /opt/local/sbin/sshd: symbol mkdtemp: referenced symbol not found Killed I see that '#define HAVE_MKDTEMP 1' is set in 'config.h', but Solaris does not have that function. I rebuilt with that commented out; 'make tests' still fails, but 'sshd' now starts. Any ideas what is missing in 'configure', or how the 'make tests' didn't catch that 'sshd' won't run? Thanks, Mike -- Mike Peterson Information Security Analyst - Audit E-mail: mikep at noc.utoronto.ca WWW: http://www.noc.utoronto.ca/ Tel: 416-978-5230 Fax: 416-978-6620 From sachin3072004 at gmail.com Wed Mar 26 06:40:02 2014 From: sachin3072004 at gmail.com (Sachin Gupta) Date: Tue, 25 Mar 2014 12:40:02 -0700 Subject: bug-1215 Message-ID: Hello Everyone, I am a newbie here. I am supposed to upgrade openssh with pam user authentication enabled on centos 5.2 machine. I was wondering patches mentioned in the following bug are available in openssh 6.5. https://bugzilla.mindrot.org/show_bug.cgi?id=1215 Or do I need to apply these patches on openssh 6.5 source code ? Thanks Sachin From djm at mindrot.org Wed Mar 26 19:24:39 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 26 Mar 2014 19:24:39 +1100 (EST) Subject: bug-1215 In-Reply-To: References: Message-ID: On Tue, 25 Mar 2014, Sachin Gupta wrote: > Hello Everyone, > > I am a newbie here. > I am supposed to upgrade openssh with pam user authentication enabled on > centos 5.2 machine. > I was wondering patches mentioned in the following bug are available in > openssh 6.5. > https://bugzilla.mindrot.org/show_bug.cgi?id=1215 > > Or do I need to apply these patches on openssh 6.5 source code ? OpenSSH doesn't include those patches (and won't), so if you want them you'll have to apply them yourself. Instead of these patches, I'd recommend you use a nss module to provide username to account mapping. Then you can use unpatched OpenSSH. -d From mancha1 at zoho.com Thu Mar 27 01:43:50 2014 From: mancha1 at zoho.com (mancha) Date: Wed, 26 Mar 2014 14:43:50 +0000 Subject: SSHFP issue Message-ID: <20140326144350.GA25444@zoho.com> Have you seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 --mancha From bowman at math.utah.edu Thu Mar 27 03:29:37 2014 From: bowman at math.utah.edu (Pieter Bowman) Date: Wed, 26 Mar 2014 10:29:37 -0600 (MDT) Subject: Bug? between OpenSSH 6.4p1 and 6.5p1(also 6.6p1) In-Reply-To: Your message of Fri, 21 Mar 2014 17:53:15 -0700 Message-ID: >> ... >> The ssh -vvv output might be of a little interest. I'm particularly >> curious as to whether you get the messages that you quoted with each >> keysign request or just the one for the ed25519 key. >> >> The behavour sounds like there is a version mismatch which is causing it >> to choke on the ed25519 key. You indicate that the correct ssh-keysign >> is being invoked, or at least the right path is used. Try running >> strings on the executable and grep for ed25519. >> >> Were yyou deliberately failing the two password prompts, or is that >> anouther aspect of the problem? >> ... The two password prompts are some aspect of the problem as the first one doesn't pause to wait for any input. Here is the output of "ssh -vvv" from both ssh 6.4p1 and 6.6p1 talking to the same sshd (6.5p1) and using the same ssh-keysign (6.6p1). I know I'm mixing things a bit, but the behavior is the same no matter which sshd is being used. I replaced hostname, IP address and home directory paths. -----------------------------OpenSSH6.4p1----------------------------- OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to [] port 22. debug1: Connection established. debug1: could not open key file '/etc/ssh/ssh_host_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_rsa-cert type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: identity file /.ssh/id_dsa-cert type -1 debug1: identity file /.ssh/id_ecdsa type -1 debug1: identity file /.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5 debug1: match: OpenSSH_6.5 pat OpenSSH* debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type DSA in file /etc/ssh/ssh_known_hosts:416 debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:417 debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:418 debug3: load_hostkeys: loaded 3 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss, debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5-etm at openssh.com debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none debug2: mac_setup: found hmac-md5-etm at openssh.com debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA a6:9e:89:40:33:63:d6:6f:86:ae:58:02:2a:32:dd:ce debug3: load_hostkeys: loading entries for host "" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type DSA in file /etc/ssh/ssh_known_hosts:416 debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:417 debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:418 debug3: load_hostkeys: loaded 3 keys debug3: load_hostkeys: loading entries for host "" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type DSA in file /etc/ssh/ssh_known_hosts:416 debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:417 debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:418 debug3: load_hostkeys: loaded 3 keys debug1: Host '' is known and matches the ECDSA host key. debug1: Found key in /etc/ssh/ssh_known_hosts:417 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa ((nil)), debug2: key: /.ssh/id_dsa ((nil)), debug2: key: /.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug3: start over, passed a different list publickey,password,keyboard-interactive,hostbased debug3: preferred hostbased,publickey,keyboard-interactive,password debug3: authmethod_lookup hostbased debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: No more client hostkeys for hostbased authentication. debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa: No such file or directory debug1: Trying private key: /.ssh/id_dsa debug3: no such identity: /.ssh/id_dsa: No such file or directory debug1: Trying private key: /.ssh/id_ecdsa debug3: no such identity: /.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password -----------------------------OpenSSH6.4p1----------------------------- -----------------------------OpenSSH6.6p1----------------------------- OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to [] port 22. debug1: Connection established. debug1: could not open key file '/etc/ssh/ssh_host_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': Permission denied debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_rsa-cert type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: identity file /.ssh/id_dsa-cert type -1 debug1: identity file /.ssh/id_ecdsa type -1 debug1: identity file /.ssh/id_ecdsa-cert type -1 debug1: identity file /.ssh/id_ed25519 type -1 debug1: identity file /.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5 debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type DSA in file /etc/ssh/ssh_known_hosts:416 debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:417 debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:418 debug3: load_hostkeys: loaded 3 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss,ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup hmac-md5-etm at openssh.com debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none debug2: mac_setup: setup hmac-md5-etm at openssh.com debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA a6:9e:89:40:33:63:d6:6f:86:ae:58:02:2a:32:dd:ce debug3: load_hostkeys: loading entries for host "" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type DSA in file /etc/ssh/ssh_known_hosts:416 debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:417 debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:418 debug3: load_hostkeys: loaded 3 keys debug3: load_hostkeys: loading entries for host "" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type DSA in file /etc/ssh/ssh_known_hosts:416 debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:417 debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:418 debug3: load_hostkeys: loaded 3 keys debug1: Host '' is known and matches the ECDSA host key. debug1: Found key in /etc/ssh/ssh_known_hosts:417 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa ((nil)), debug2: key: /.ssh/id_dsa ((nil)), debug2: key: /.ssh/id_ecdsa ((nil)), debug2: key: /.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug3: start over, passed a different list publickey,password,keyboard-interactive,hostbased debug3: preferred hostbased,publickey,keyboard-interactive,password debug3: authmethod_lookup hostbased debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug2: userauth_hostbased: chost . debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 888 no matching hostkey found ssh_keysign: no reply key_sign failed debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa: No such file or directory debug1: Trying private key: /.ssh/id_dsa debug3: no such identity: /.ssh/id_dsa: No such file or directory debug1: Trying private key: /.ssh/id_ecdsa debug3: no such identity: /.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /.ssh/id_ed25519 debug3: no such identity: /.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password debug3: packet_send2: adding 64 (len 47 padlen 17 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased Permission denied, please try again. -----------------------------OpenSSH6.6p1----------------------------- From djm at mindrot.org Thu Mar 27 11:31:33 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Mar 2014 11:31:33 +1100 (EST) Subject: Bug? between OpenSSH 6.4p1 and 6.5p1(also 6.6p1) In-Reply-To: References: Message-ID: On Wed, 26 Mar 2014, Pieter Bowman wrote: > Here is the output of "ssh -vvv" from both ssh 6.4p1 and 6.6p1 talking > to the same sshd (6.5p1) and using the same ssh-keysign (6.6p1). I > know I'm mixing things a bit, but the behavior is the same no matter > which sshd is being used. I replaced hostname, IP address and home > directory paths. Are you sure that the ssh-keysign is really OpenSSH 6.6p1's? The error you are getting below is consistent with an old ssh-keysign choking on a key type that it doesn't understand (e.g. Ed25519). In any case, this patch to ssh-keysign might help us understand what it happening: diff --git ssh-keysign.c ssh-keysign.c index 4b0996f..cf2cbfd 100644 --- ssh-keysign.c +++ ssh-keysign.c @@ -150,7 +150,7 @@ main(int argc, char **argv) struct passwd *pw; int key_fd[NUM_KEYTYPES], i, found, version = 2, fd; u_char *signature, *data; - char *host; + char *host, *fp; u_int slen, dlen; u_int32_t rnd[256]; @@ -236,8 +235,11 @@ main(int argc, char **argv) break; } } - if (!found) - fatal("no matching hostkey found"); + if (!found) { + fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + fatal("no matching hostkey found for key %s %s", + key_type(key), fp); + } if (key_sign(keys[i], &signature, &slen, data, dlen) != 0) fatal("key_sign failed"); From djm at mindrot.org Thu Mar 27 11:35:26 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Mar 2014 11:35:26 +1100 (EST) Subject: SSHFP issue In-Reply-To: <20140326144350.GA25444@zoho.com> References: <20140326144350.GA25444@zoho.com> Message-ID: On Wed, 26 Mar 2014, mancha wrote: > Have you seen this? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 Yes, it's a bug but not one I'd consider serious enough to force a release. Here's an untested patch that unconditionally downgrades certificate keys to plain ones before attempting SSHFP lookup. -d diff --git sshconnect.c sshconnect.c index 8c38b16..b2ec48a 100644 --- sshconnect.c +++ sshconnect.c @@ -1193,29 +1193,39 @@ verify_host_key(char *host, struct sockaddr *hostaddr, Key *host_key) { int flags = 0; char *fp; + Key *plain = NULL; fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); debug("Server host key: %s %s", key_type(host_key), fp); free(fp); - /* XXX certs are not yet supported for DNS */ - if (!key_is_cert(host_key) && options.verify_host_key_dns && - verify_host_key_dns(host, hostaddr, host_key, &flags) == 0) { - if (flags & DNS_VERIFY_FOUND) { - - if (options.verify_host_key_dns == 1 && - flags & DNS_VERIFY_MATCH && - flags & DNS_VERIFY_SECURE) - return 0; - - if (flags & DNS_VERIFY_MATCH) { - matching_host_key_dns = 1; - } else { - warn_changed_key(host_key); - error("Update the SSHFP RR in DNS with the new " - "host key to get rid of this message."); + if (options.verify_host_key_dns) { + /* + * XXX certs are not yet supported for DNS, so downgrade + * them and try the plain key. + */ + plain = key_from_private(host_key); + if (key_is_cert(plain)) + key_drop_cert(plain); + if (verify_host_key_dns(host, hostaddr, plain, &flags) == 0) { + if (flags & DNS_VERIFY_FOUND) { + if (options.verify_host_key_dns == 1 && + flags & DNS_VERIFY_MATCH && + flags & DNS_VERIFY_SECURE) { + key_free(plain); + return 0; + } + if (flags & DNS_VERIFY_MATCH) { + matching_host_key_dns = 1; + } else { + warn_changed_key(plain); + error("Update the SSHFP RR in DNS " + "with the new host key to get rid " + "of this message."); + } } } + key_free(plain); } return check_host_key(host, hostaddr, options.port, host_key, RDRW, From djm at mindrot.org Thu Mar 27 11:37:54 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Mar 2014 11:37:54 +1100 (EST) Subject: ProxyCommand as both a resolver and connector In-Reply-To: References: Message-ID: On Sun, 23 Mar 2014, Igor Bukanov wrote: > I see that the hostname canonicalization configuration options is still > rather limited. As that works on DNS level they are of not use if one has > to use ProxyCommand to connect over a proxy connection or through a common > gateway name where one uses different port numbers to connect to different > intranet names. > > What would be ideal is to extend the ProxyCommand to both return the > resolved universal name for the given short name and to connect to that > universal name. For example, the proxy can first print the resolved name on > its stdout before proceeding with other data. It's an interesting idea, probably best used in conjunction with the fd- passing proxy mode. I don't know if I'm interested enough to implement it myself, but you should file an enhancement bug at https://bugzilla.mindrot.org so it doesn't get lost. -d From djm at mindrot.org Thu Mar 27 11:39:19 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Mar 2014 11:39:19 +1100 (EST) Subject: SCTP support for the common openssh source? In-Reply-To: <532D6AFB.2010109@r.paypc.com> References: <532D5904.1070101@gmail.com> <532D6AFB.2010109@r.paypc.com> Message-ID: On Sat, 22 Mar 2014, Morham wrote: > > > A second benefit of having SCTP support as a standard > > feature in OpenSSH for all platforms supporting SCTP would > > be kind of social pressure for more and more platforms to > > aim at adopting SCTP. > > What is the benefit to this? Yeah; what does OpenSSH gain by implementing SCTP support? It seems like a maintenance cost without any benefit. -d From bowman at math.utah.edu Thu Mar 27 12:19:15 2014 From: bowman at math.utah.edu (Pieter Bowman) Date: Wed, 26 Mar 2014 19:19:15 -0600 (MDT) Subject: Bug? between OpenSSH 6.4p1 and 6.5p1(also 6.6p1) In-Reply-To: Your message of Thu, 27 Mar 2014 11:31:33 +1100 (EST) Message-ID: >> ... >> Are you sure that the ssh-keysign is really OpenSSH 6.6p1's? The error >> you are getting below is consistent with an old ssh-keysign choking >> on a key type that it doesn't understand (e.g. Ed25519). >> ... I applied the patch to ssh-keysign.c, compiled from scratch and did the install. Here are the differences between the log I sent previously and for the current install (I went ahead and started the 6.6p1 sshd): 25,26c25,26 < debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5 < debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000 --- > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 > debug1: match: OpenSSH_6.6 pat OpenSSH* compat 0x04000000 127c127 < no matching hostkey found --- > no matching hostkey found for key ED25519 41:cd:e0:03:3f:32:4e:a3:1c:34:b9:c9:8d:cc:d8:d2 So yes, the key in question is the ED25519 key. The files /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_ed25519_key.pub, exist. However, the ED25519 key didn't exist in the /etc/ssh/ssh_known_hosts file. Adding that key changes the behavior some, but I still get the following when running 'ssh ': no matching hostkey found for key ED25519 41:cd:e0:03:3f:32:4e:a3:1c:34:b9:c9:8d:cc:d8:d2 ssh_keysign: no reply key_sign failed bowman@'s password: Permission denied, please try again. bowman@'s password: Including the spurious password prompt, which doesn't wait for input. Pieter From t.charles at infass.com Fri Mar 28 03:58:10 2014 From: t.charles at infass.com (Thierry CHARLES) Date: Thu, 27 Mar 2014 17:58:10 +0100 Subject: AIX SFTP with chroot : conection closed without error message Message-ID: <533458A2.2070907@infass.com> Hello, I'm trying to setup a chroot for one user on my AIX 5.2 system I have tried with openssh 5.0 (don't know where it comes from) and as it didn't work, I have downloaded and compiled the current version (6.6p1) When I connect, password is checked, chroot is done, sftp subsystem is accepted, but I get disconnected without any error Below is all can say about my config (after hours of googling) ... Thanks you for any hint that will help making it operational ! Thierry ====================== $ ls -l /usr/local/ssh/etc/sshd_config -rw-r--r-- 1 root system 3864 Mar 27 15:55 /usr/local/ssh/etc/sshd_config ====================== $ cat /usr/local/ssh/etc/sshd_config | sed "s/#.*//g" | egrep -v "^$" AuthorizedKeysFile .ssh/authorized_keys UsePrivilegeSeparation sandbox Subsystem sftp /usr/local/ssh/libexec/sftp-server Match User cpdp ChrootDirectory /cpdp ForceCommand internal-sftp ==> I have also tried to set sftp subsystem to "internal-sftp" but it doesn't work better ====================== $ ls -ld /cpdp drwxr-xr-x 4 root system 512 Mar 27 14:41 /cpdp ==> the chroot path is root owned and only root-writable ====================== $ find /cpdp /cpdp /cpdp/home /cpdp/home/cpdp ==> I have re-created the home directory for the cpdp user but it isn't better ====================== SERVER LOG ====================== $ /usr/local/ssh/sbin/sshd -ddddd -p2222 debug2: load_server_config: filename /usr/local/ssh/etc/sshd_config debug2: load_server_config: done config len = 324 debug2: parse_server_config: config /usr/local/ssh/etc/sshd_config len 324 debug3: /usr/local/ssh/etc/sshd_config:54 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /usr/local/ssh/etc/sshd_config:110 setting UsePrivilegeSeparation sandbox debug3: /usr/local/ssh/etc/sshd_config:126 setting Subsystem sftp /usr/local/ssh/libexec/sftp-server debug3: checking syntax for 'Match User cpdp' debug1: sshd version OpenSSH_6.6, OpenSSL 0.9.8h 28 May 2008 debug3: Incorrect RSA1 identifier debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type RSA debug3: Incorrect RSA1 identifier debug3: Could not load "/usr/local/ssh/etc/ssh_host_rsa_key" as a RSA1 public key debug1: private host key: #0 type 1 RSA debug3: Incorrect RSA1 identifier debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type DSA debug3: Incorrect RSA1 identifier debug3: Could not load "/usr/local/ssh/etc/ssh_host_dsa_key" as a RSA1 public key debug1: private host key: #1 type 2 DSA debug3: Incorrect RSA1 identifier debug3: Incorrect RSA1 identifier debug3: Could not load "/usr/local/ssh/etc/ssh_host_ed25519_key" as a RSA1 public key debug1: private host key: #2 type 4 ED25519 debug1: rexec_argv[0]='/usr/local/ssh/sbin/sshd' debug1: rexec_argv[1]='-ddddd' debug1: rexec_argv[2]='-p2222' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2222 on 0.0.0.0. Server listening on 0.0.0.0 port 2222. debug2: fd 4 setting O_NONBLOCK debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 2222 on ::. Bind to port 2222 on :: failed: Address already in use. debug1: fd 4 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 324 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 10.1.0.161 port 54046 on 10.1.0.1 port 2222 debug1: Client protocol version 2.0; client software version OpenSSH_6.5p1 Debian-6 debug1: match: OpenSSH_6.5p1 Debian-6 pat OpenSSH* compat 0x04000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 debug2: fd 3 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing rlimit sandbox debug2: Network child is on pid 89674 debug3: preauth child monitor started debug3: privsep user:group 210:202 [preauth] debug1: permanently_set_uid: 210/202 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519 [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] debug2: kex_parse_kexinit: reserved 0 [preauth] debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] debug2: kex_parse_kexinit: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] debug2: kex_parse_kexinit: reserved 0 [preauth] debug2: mac_setup: setup hmac-md5-etm at openssh.com [preauth] debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none [preauth] debug2: mac_setup: setup hmac-md5-etm at openssh.com [preauth] debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug3: mm_key_sign entering [preauth] debug3: mm_request_send entering: type 6 [preauth] debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] debug3: mm_request_receive_expect entering: type 7 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_sign debug3: mm_answer_sign: signature 2004af48(83) debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug2: kex_derive_keys [preauth] debug2: set_newkeys: mode 1 [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug2: set_newkeys: mode 0 [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user cpdp service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug3: mm_getpwnamallow entering [preauth] debug3: mm_request_send entering: type 8 [preauth] debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] debug3: mm_request_receive_expect entering: type 9 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 8 debug3: mm_answer_pwnamallow debug3: Trying to reverse map address 10.1.0.161. debug2: parse_server_config: config reprocess config len 324 debug3: checking match for 'User cpdp' user cpdp host pctotc addr 10.1.0.161 laddr 10.1.0.1 lport 2222 debug1: user cpdp matched 'User cpdp' at line 136 debug3: match found debug3: reprocess config:137 setting ChrootDirectory /cpdp debug3: reprocess config:138 setting ForceCommand internal-sftp debug3: AIX/setauthdb set registry 'files' debug3: aix_restoreauthdb: restoring old registry '' debug3: AIX/loginrestrictions returned 0 msg (none) debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 9 debug2: monitor_read: 8 used once, disabling now debug2: input_userauth_request: setting up authctxt for cpdp [preauth] debug3: mm_inform_authserv entering [preauth] debug3: mm_request_send entering: type 4 [preauth] debug2: input_userauth_request: try method none [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 4 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 4 used once, disabling now debug1: userauth-request for user cpdp service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug2: input_userauth_request: try method publickey [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug3: mm_key_allowed entering [preauth] debug3: mm_request_send entering: type 22 [preauth] debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] debug3: mm_request_receive_expect entering: type 23 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 22 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 2004b1d8 debug1: temporarily_use_uid: 212/1 (e=0/0) debug1: trying public key file /home/cpdp/.ssh/authorized_keys debug1: Could not open authorized keys '/home/cpdp/.ssh/authorized_keys': No such file or directory debug1: restore_uid: 0/0 Failed publickey for cpdp from 10.1.0.161 port 54046 ssh2: DSA 6f:bf:40:de:ee:5c:1c:9f:70:71:68:cf:41:de:f0:5f debug3: mm_answer_keyallowed: key 2004b1d8 is not allowed debug3: mm_request_send entering: type 23 debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] debug1: userauth-request for user cpdp service ssh-connection method keyboard-interactive [preauth] debug1: attempt 2 failures 1 [preauth] debug2: input_userauth_request: try method keyboard-interactive [preauth] debug1: keyboard-interactive devs [preauth] debug1: auth2_challenge: user=cpdp devs= [preauth] debug1: kbdint_alloc: devices '' [preauth] debug2: auth2_challenge_start: devices [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] debug1: userauth-request for user cpdp service ssh-connection method password [preauth] debug1: attempt 3 failures 2 [preauth] debug2: input_userauth_request: try method password [preauth] debug3: mm_auth_password entering [preauth] debug3: mm_request_send entering: type 12 [preauth] debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth] debug3: mm_request_receive_expect entering: type 13 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 12 debug3: AIX/authenticate result 0, authmsg debug3: AIX SYSTEM attribute compat debug3: AIX/setauthdb set registry 'files' debug3: AIX/passwdexpired returned 1 msg You are required to change your password. Please choose a new one. debug3: aix_restoreauthdb: restoring old registry '' debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 13 Accepted password for cpdp from 10.1.0.161 port 54046 ssh2 debug3: AIX/setauthdb set registry 'files' debug1: AIX/loginsuccess: msg Last login: Thu Mar 27 16:00:44 2014 on ssh from pctotc debug3: aix_restoreauthdb: restoring old registry '' debug1: monitor_child_preauth: cpdp has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 26 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 2006a398(134) debug2: mac_setup: setup hmac-md5-etm at openssh.com debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 2006a398(134) debug2: mac_setup: setup hmac-md5-etm at openssh.com debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_auth_password: user authenticated [preauth] debug3: mm_send_keystate: Sending new keys: 200516c8 2004ab58 [preauth] debug3: mm_newkeys_to_blob: converting 200516c8 [preauth] debug3: mm_newkeys_to_blob: converting 2004ab58 [preauth] debug3: mm_send_keystate: New keys have been sent [preauth] debug3: mm_send_keystate: Sending compression state [preauth] debug3: mm_request_send entering: type 26 [preauth] debug3: mm_send_keystate: Finished sending state [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug3: ssh_sandbox_parent_finish: finished debug3: AIX/UsrInfo: set len 23 debug3: safely_chroot: checking '/' debug3: safely_chroot: checking '/cpdp' Changed root directory to "/cpdp" debug1: permanently_set_uid: 212/1 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 User child is on pid 89676 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug2: Ignoring env request LANG: disallowed name debug1: server_input_channel_req: channel 0 request subsystem reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req subsystem debug2: subsystem request for sftp by user cpdp debug1: subsystem: cannot stat /usr/local/ssh/libexec/sftp-server: No such file or directory debug1: subsystem: exec() /usr/local/ssh/libexec/sftp-server Starting session: forced-command (config) 'internal-sftp' for cpdp from 10.1.0.161 port 54046 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x08 debug2: fd 9 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug2: fd 11 setting O_NONBLOCK debug2: channel 0: read 83 from efd 11 debug3: channel 0: discard efd debug1: Received SIGCHLD. debug1: session_by_pid: pid 71070 debug1: session_exit_message: session 0 channel 0 pid 71070 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: send eow debug2: channel 0: output open -> closed debug2: channel 0: read<=0 rfd 9 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: read 0 from efd 11 debug2: channel 0: closing read-efd 11 debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: send close debug2: notify_done: reading debug3: channel 0: will not send data after close debug2: channel 0: rcvd close Received disconnect from 10.1.0.161: 11: disconnected by user debug1: do_cleanup debug3: mm_request_receive entering debug1: do_cleanup ====================== CLIENT LOG ====================== $ sftp -P 2222 -vvv cpdp at 10.1.0.1 OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.1.0.1 [10.1.0.1] port 2222. debug1: Connection established. debug1: identity file /home/tc/.ssh/id_rsa type -1 debug1: identity file /home/tc/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/tc/.ssh/id_dsa" as a RSA1 public key debug1: identity file /home/tc/.ssh/id_dsa type 2 debug1: identity file /home/tc/.ssh/id_dsa-cert type -1 debug1: identity file /home/tc/.ssh/id_ecdsa type -1 debug1: identity file /home/tc/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/tc/.ssh/id_ed25519 type -1 debug1: identity file /home/tc/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Debian-6 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 debug1: match: OpenSSH_6.6 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [10.1.0.1]:2222 debug3: load_hostkeys: loading entries for host "[10.1.0.1]:2222" from file "/home/tc/.ssh/known_hosts" debug3: load_hostkeys: found key type ED25519 in file /home/tc/.ssh/known_hosts:177 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5-etm at openssh.com debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none debug2: mac_setup: found hmac-md5-etm at openssh.com debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ED25519 51:c3:32:61:dd:77:32:87:14:2d:78:21:17:53:bb:8d debug3: put_host_port: [10.1.0.1]:2222 debug3: put_host_port: [10.1.0.1]:2222 debug3: load_hostkeys: loading entries for host "[10.1.0.1]:2222" from file "/home/tc/.ssh/known_hosts" debug3: load_hostkeys: found key type ED25519 in file /home/tc/.ssh/known_hosts:177 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "[10.1.0.1]:2222" from file "/home/tc/.ssh/known_hosts" debug3: load_hostkeys: found key type ED25519 in file /home/tc/.ssh/known_hosts:177 debug3: load_hostkeys: loaded 1 keys debug1: Host '[10.1.0.1]:2222' is known and matches the ED25519 host key. debug1: Found key in /home/tc/.ssh/known_hosts:177 debug1: ssh_ed25519_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/tc/.ssh/id_rsa ((nil)), debug2: key: /home/tc/.ssh/id_dsa (0x7fe98cc92070), debug2: key: /home/tc/.ssh/id_ecdsa ((nil)), debug2: key: /home/tc/.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/tc/.ssh/id_rsa debug3: no such identity: /home/tc/.ssh/id_rsa: No such file or directory debug1: Offering DSA public key: /home/tc/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/tc/.ssh/id_ecdsa debug3: no such identity: /home/tc/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/tc/.ssh/id_ed25519 debug3: no such identity: /home/tc/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password cpdp at 10.1.0.1's password: debug3: packet_send2: adding 64 (len 49 padlen 15 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). Authenticated to 10.1.0.1 ([10.1.0.1]:2222). debug2: fd 4 setting O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x08 debug2: client_session2_setup: id 0 debug1: Sending environment. debug3: Ignored env SSH_AGENT_PID debug3: Ignored env KDE_MULTIHEAD debug3: Ignored env DM_CONTROL debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env XDG_SESSION_COOKIE debug3: Ignored env XDM_MANAGED debug3: Ignored env GTK2_RC_FILES debug3: Ignored env KONSOLE_DBUS_SERVICE debug3: Ignored env KONSOLE_PROFILE_NAME debug3: Ignored env GS_LIB debug3: Ignored env GTK_RC_FILES debug3: Ignored env WINDOWID debug3: Ignored env SHELL_SESSION_ID debug3: Ignored env KDE_FULL_SESSION debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env XCURSOR_SIZE debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env SESSION_MANAGER debug3: Ignored env DESKTOP_SESSION debug3: Ignored env PATH debug3: Ignored env PWD debug3: Ignored env KONSOLE_DBUS_WINDOW debug3: Ignored env KDE_SESSION_UID debug1: Sending env LANG = fr_FR.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env KONSOLE_DBUS_SESSION debug3: Ignored env HOME debug3: Ignored env COLORFGBG debug3: Ignored env SHLVL debug3: Ignored env KDE_SESSION_VERSION debug3: Ignored env LANGUAGE debug3: Ignored env XCURSOR_THEME debug3: Ignored env LOGNAME debug3: Ignored env XDG_DATA_DIRS debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env WINDOWPATH debug3: Ignored env PROFILEHOME debug3: Ignored env DISPLAY debug3: Ignored env QT_PLUGIN_PATH debug3: Ignored env XDG_CURRENT_DESKTOP debug3: Ignored env _ debug1: Sending subsystem: sftp debug2: channel 0: request subsystem confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: subsystem request accepted on channel 0 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug1: fd 0 clearing O_NONBLOCK debug3: fd 1 is not O_NONBLOCK Transferred: sent 3104, received 2136 bytes, in 0.0 seconds Bytes per second: sent 234989.4, received 161706.6 debug1: Exit status 1 Connection closed -- *Thierry CHARLES* Infass Syst?mes -------------- next part -------------- A non-text attachment was scrubbed... Name: t_charles.vcf Type: text/x-vcard Size: 273 bytes Desc: not available URL: From Geoff_Lowe at McAfee.com Sat Mar 29 03:30:05 2014 From: Geoff_Lowe at McAfee.com (Geoff_Lowe at McAfee.com) Date: Fri, 28 Mar 2014 16:30:05 +0000 Subject: CVE-2014-2653 Message-ID: <2B830C10D3A65B42856BB9DDF14806902BBE69@MIVEXAMER1N2.corp.nai.org> Are there plans to integrate the patch contributed by Mark Wooding into the official OpenSSH distribution? (See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513) for the patch.) Or perhaps the OpenSSH team has other plans...? Thanks. From mancha1 at zoho.com Sat Mar 29 03:42:13 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 28 Mar 2014 16:42:13 +0000 Subject: CVE-2014-2653 In-Reply-To: <2B830C10D3A65B42856BB9DDF14806902BBE69@MIVEXAMER1N2.corp.nai.org> References: <2B830C10D3A65B42856BB9DDF14806902BBE69@MIVEXAMER1N2.corp.nai.org> Message-ID: <20140328164213.GA1815@zoho.com> On Fri, Mar 28, 2014 at 04:30:05PM +0000, Geoff_Lowe at McAfee.com wrote: > Are there plans to integrate the patch contributed by Mark Wooding into the official OpenSSH distribution? (See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513) for the patch.) > > Or perhaps the OpenSSH team has other plans...? > See: http://thread.gmane.org/gmane.network.openssh.devel/20679 From quantheory at gmail.com Sat Mar 29 03:55:00 2014 From: quantheory at gmail.com (Sean Patrick Santos) Date: Fri, 28 Mar 2014 10:55:00 -0600 Subject: Using -Ocancel on dynamically allocated ports Message-ID: Greetings, So, the typical use of -Ocancel is quite straightforward: > ssh -Oforward -R 12345:127.0.0.1:56789 user at remote > ssh -Ocancel -R 12345:127.0.0.1:56789 user at remote But this is not so good: > ssh -Oforward -R 0:127.0.0.1:56789 user at remote Allocated port 12345 for remote forward to 127.0.0.1:56789 12345 > ssh -Ocancel -R 0:127.0.0.1:56789 user at remote mux_client_forward: forwarding request failed: port not in permitted opens muxclient: master cancel forward request failed > ssh -Ocancel -R 12345:127.0.0.1:56789 user at remote mux_client_forward: forwarding request failed: port not forwarded muxclient: master cancel forward request failed I'm not sure whether this is a "bug" or not, because I really don't understand what the intended behavior is. But I think that at least in the second case, where you know what port is allocated, using -Ocancel should work to cancel the forwarding request. -Sean Patrick Santos