From aixtools at gmail.com  Sun Mar  1 02:32:31 2015
From: aixtools at gmail.com (Michael Felt)
Date: Sat, 28 Feb 2015 16:32:31 +0100
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <CANvxniVGvPjvZgOvsS6YXyLm5r=an1-OvzcnH6Lxu3GfKSXCnw@mail.gmail.com>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <alpine.BSO.2.11.1502200945050.4850@natsu.mindrot.org>
 <CANvxniW13J+3UREHECtbwZd8sLBt+Q3EYT+Z5FKzy7mQGC_tDA@mail.gmail.com>
 <CANvxniVGvPjvZgOvsS6YXyLm5r=an1-OvzcnH6Lxu3GfKSXCnw@mail.gmail.com>
Message-ID: <CANvxniV_c4-MvqVHdrJfAQhnh=AELpA44RA40p9Hb0iXR0o35w@mail.gmail.com>

Came this far - then ended - even with LIBPATH exported...

APOLOGIES --- This mail was in DRAFT --- It's purpose is to show that
setting LIBPATH alone is not enough to pass all the tests. Apparently,
somewhere LIBPATH gets unset - as it was 'exported' before 'make tests'

FYI only!

test try ciphers: proto 1 cipher 3des
test try ciphers: proto 1 cipher blowfish
ok try ciphers
run test yes-head.sh ...
sh: There is no process to read data written to a pipe.
ok yes pipe head
run test login-timeout.sh ...
ok connect after login grace timeout
run test agent.sh ...
ssh-add -l via agent fwd proto 1 failed (exit code 255)
exec(): 0509-036 Cannot load program /data/prj/openbsd/openssh/openssh/ssh
because of the following errors:
        0509-150   Dependent module /usr/lib/libcrypto.a(libcrypto.so.32)
could not be loaded.
        0509-152   Member libcrypto.so.32 is not found in archive
agent fwd proto 1 failed (exit code 255)
ssh-add -l via agent fwd proto 2 failed (exit code 255)
exec(): 0509-036 Cannot load program /data/prj/openbsd/openssh/openssh/ssh
because of the following errors:
        0509-150   Dependent module /usr/lib/libcrypto.a(libcrypto.so.32)
could not be loaded.
        0509-152   Member libcrypto.so.32 is not found in archive
agent fwd proto 2 failed (exit code 255)
failed simple agent test
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/data/prj/openbsd/openssh/openssh/regress'
make: *** [tests] Error 2


On Fri, Feb 27, 2015 at 3:19 PM, Michael Felt <aixtools at gmail.com> wrote:

> New test - using AIX 5.3 TL7 - but against libressl-2.1.4
>
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating buildpkg.sh
> config.status: creating opensshd.init
> config.status: creating openssh.xml
> config.status: creating openbsd-compat/Makefile
> config.status: creating openbsd-compat/regress/Makefile
> config.status: creating survey.sh
> config.status: creating config.h
> config.status: config.h is unchanged
>
> OpenSSH has been configured with the following options:
>                      User binaries: /opt/bin
>                    System binaries: /opt/sbin
>                Configuration files: /opt/etc
>                    Askpass program: /opt/libexec/ssh-askpass
>                       Manual pages: /opt/share/man/manX
>                           PID file: /opt/etc
>   Privilege separation chroot path: /var/empty
>             sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/opt/bin
>                     Manpage format: man
>                        PAM support: no
>                    OSF SIA support: no
>                  KerberosV support: no
>                    SELinux support: no
>                  Smartcard support:
>                      S/KEY support: no
>               MD5 password support: no
>                    libedit support: no
>   Solaris process contract support: no
>            Solaris project support: no
>        IP address in $DISPLAY hack: no
>            Translate v4 in v6 hack: no
>                   BSD Auth support: no
>               Random number source: OpenSSL internal ONLY
>              Privsep sandbox style: rlimit
>
>               Host: powerpc-ibm-aix5.3.0.0
>           Compiler: xlc
>     Compiler flags: -g
> Preprocessor flags: -I/opt/libressl/include
>       Linker flags: -L/opt/libressl/lib  -blibpath:/usr/lib:/lib
>          Libraries: -lcrypto -lz
>
> One problem coming directly is that the -L flag (-L/opt/libressl/lib is
> not being included in the -blibpath so the programs link, but do not run.
> I am sure there is a way for me to modify the blibpath - BUT - I ask you
> do consider inserting an openssl-dir path when it is not
> already in the blibpath variable.
>
> rm ssh
> make
> xlc -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/ -L/opt/libressl/lib  -blibpath:/usr/lib:/lib -lssh
> -lopenbsd-compat  -lcrypto -lz
>
> root at x064:[/data/prj/openbsd/openssh/openssh]dump -H ssh
>
> ssh:
>
>                         ***Loader Section***
>                       Loader Header Information
> VERSION#         #SYMtableENT     #RELOCent        LENidSTR
> 0x00000001       0x0000014a       0x0000075a       0x0000003b
>
> #IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
> 0x00000003       0x00007748       0x00000c6d       0x00007783
>
>
>                         ***Import File Strings***
> INDEX  PATH                          BASE
> MEMBER
> 0
> /usr/lib:/lib
> 1                                    libc.a
> shr.o
> 2                                    libcrypto.a
> libcrypto.so.32
> root at x064:[/data/prj/openbsd/openssh/openssh]ldd ssh
> ssh needs:
>          /usr/lib/libc.a(shr.o)
>          /usr/lib/libcrypto.a(libcrypto.so.32)
> ar: 0707-109 Member name libcrypto.so.32 does not exist.
> dump: /tmp/tmpdir733264/extract/libcrypto.so.32: 0654-106 Cannot open the
> specified file.
>          /unix
>          /usr/lib/libcrypt.a(shr.o)
>
> Modified blibpath:
>
> xlc -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/ -L/opt/libressl/lib  -blibpath:/opt/libressl/
> lib:/usr/lib:/lib -lssh -lopenbsd-compat  -lcrypto -lz
>
> root at x064:[/data/prj/openbsd/openssh/openssh]ldd ssh
> ssh needs:
>          /usr/lib/libc.a(shr.o)
>          /opt/libressl/lib/libcrypto.a(libcrypto.so.32)
>          /unix
>          /usr/lib/libcrypt.a(shr.o)
>          /usr/lib/libperfstat.a(shr.o)
>          /usr/lib/libpthread.a(shr_xpg5.o)
>          /usr/lib/libpthreads.a(shr_xpg5.o)
>          /usr/lib/libcfg.a(shr.o)
>          /usr/lib/libodm.a(shr.o)
>          /usr/lib/liblvm.a(shr.o)
>          /usr/lib/libpthreads.a(shr_comm.o)
>
> This can be corrected with LIBPATH
>
> root at x064:[/data/prj/openbsd/openssh/openssh]ldd
> ssh
> ssh needs:
>          /usr/lib/libc.a(shr.o)
>          /usr/lib/libcrypto.a(libcrypto.so.32)
> ar: 0707-109 Member name libcrypto.so.32 does not exist.
> dump: /tmp/tmpdir733294/extract/libcrypto.so.32: 0654-106 Cannot open the
> specified file.
>          /unix
>          /usr/lib/libcrypt.a(shr.o)
>
> root at x064:[/data/prj/openbsd/openssh/openssh]LIBPATH=/opt/libressl/lib
> ldd ssh
> ssh needs:
>          /usr/lib/libc.a(shr.o)
>          /opt/libressl/lib/libcrypto.a(libcrypto.so.32)
>          /unix
>          /usr/lib/libcrypt.a(shr.o)
>          /usr/lib/libperfstat.a(shr.o)
>          /usr/lib/libpthread.a(shr_xpg5.o)
>          /usr/lib/libpthreads.a(shr_xpg5.o)
>          /usr/lib/libcfg.a(shr.o)
>          /usr/lib/libodm.a(shr.o)
>          /usr/lib/liblvm.a(shr.o)
>          /usr/lib/libpthreads.a(shr_comm.o)
>
>
> I shall use LIBPATH - and post - I expect all test successful - later.
>
> On Fri, Feb 27, 2015 at 2:07 PM, Michael Felt <aixtools at gmail.com> wrote:
>
>> Update - for AIX 6.1 TL9 -
>> configure: creating ./config.status
>> config.status: creating Makefile
>> config.status: creating buildpkg.sh
>> config.status: creating opensshd.init
>> config.status: creating openssh.xml
>> config.status: creating openbsd-compat/Makefile
>> config.status: creating openbsd-compat/regress/Makefile
>> config.status: creating survey.sh
>> config.status: creating config.h
>>
>> OpenSSH has been configured with the following options:
>>                      User binaries: /opt/bin
>>                    System binaries: /opt/sbin
>>                Configuration files: /opt/etc
>>                    Askpass program: /opt/libexec/ssh-askpass
>>                       Manual pages: /opt/share/man/manX
>>                           PID file: /var/run
>>   Privilege separation chroot path: /var/empty
>>             sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/opt/bin
>>                     Manpage format: man
>>                        PAM support: no
>>                    OSF SIA support: no
>>                  KerberosV support: no
>>                    SELinux support: no
>>                  Smartcard support:
>>                      S/KEY support: no
>>               MD5 password support: no
>>                    libedit support: no
>>   Solaris process contract support: no
>>            Solaris project support: no
>>        IP address in $DISPLAY hack: no
>>            Translate v4 in v6 hack: no
>>                   BSD Auth support: no
>>               Random number source: OpenSSL internal ONLY
>>              Privsep sandbox style: rlimit
>>
>>               Host: powerpc-ibm-aix6.1.0.0
>>           Compiler: xlc
>>     Compiler flags: -g
>> Preprocessor flags:
>>       Linker flags:  -blibpath:/usr/lib:/lib
>>          Libraries: -lcrypto -lz
>>
>> michael at x071:[/home/michael]lslpp -L | grep ssl
>>   openssl.base             1.0.1.510    C     F    Open Secure Socket
>> Layer
>>   openssl.man.en_US        1.0.1.510    C     F    Open Secure Socket
>> Layer
>>
>> ...
>>         tests && echo all tests passed
>> make[1]: Entering directory `/data/prj/openbsd/openssh/openssh/regress'
>> set -e ; if test -z "" ; then \
>>
>> /data/prj/openbsd/openssh/openssh/regress/unittests/sshbuf/test_sshbuf ; \
>>
>> /data/prj/openbsd/openssh/openssh/regress/unittests/sshkey/test_sshkey \
>>                 -d
>> /data/prj/openbsd/openssh/openssh/regress/unittests/sshkey/testdata ; \
>>
>> /data/prj/openbsd/openssh/openssh/regress/unittests/bitmap/test_bitmap ; \
>>         /data/prj/openbsd/openssh/openssh/regress/unittests/kex/test_kex
>> ; \
>>
>> /data/prj/openbsd/openssh/openssh/regress/unittests/hostkeys/test_hostkeys \
>>                 -d
>> /data/prj/openbsd/openssh/openssh/regress/unittests/hostkeys/testdata ; \
>> fi
>> test_sshbuf:
>> ...................................................................................................
>> 100 tests ok
>> test_sshkey:
>> .............................................................................................
>>
>> ...
>> many minutes later ...
>> ...
>> learn new primary hostkey
>> rotate primary hostkey
>> check rotate primary hostkey
>> ok hostkey rotate
>> make[1]: Leaving directory `/data/prj/openbsd/openssh/openssh/regress'
>> all tests passed
>>
>>
>>
>> On Thu, Feb 19, 2015 at 11:45 PM, Damien Miller <djm at mindrot.org> wrote:
>>
>>> On Fri, 20 Feb 2015, Damien Miller wrote:
>>>
>>> > Hi,
>>> >
>>> > OpenSSH 6.8 is almost ready for release, so we would appreciate testing
>>> > on as many platforms and systems as possible. This release contains
>>> > some substantial new features and a number of bugfixes.
>>>
>>> ...
>>>
>>> >  * ssh(1), sshd(8): Host key rotation support. Add a protocol
>>> >    extension for a server to inform a client of all its available
>>> >    host keys after authentication has completed. The client may
>>> >    record the keys in known_hosts, allowing it to upgrade to better
>>> >    host key algorithms and a server to gracefully rotate its keys.
>>> >
>>> >    The client side of this is controlled by a UpdateHostkeys config
>>> >    option (default on).
>>>
>>> Actually, the default is off. You can enable it using UpdateHostKeys=yes
>>> or UpdateHostKeys=ask
>>>
>>> -d
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>>
>>
>

From aixtools at gmail.com  Sun Mar  1 02:43:31 2015
From: aixtools at gmail.com (Michael Felt)
Date: Sat, 28 Feb 2015 16:43:31 +0100
Subject: SNAP-20150301 compiler messages on AIX
Message-ID: <CANvxniXQWfv+6yp=vDyvOaFTAicxCjW60Vesm2x4E=kJ4EZ7eQ@mail.gmail.com>

This is compiling on AIX with XL C, v11, patch 020
michael at x071:[/home/michael]xlc -qversion
IBM XL C/C++ for AIX, V11.1 (5724-X13)
Version: 11.01.0000.0020

"bsd-cray.c", line 817.23: 1506-356 (W) Compilation unit is empty.
"kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
"glob.c", line 93.9: 1506-236 (W) Macro name TILDE has been redefined.
"glob.c", line 93.9: 1506-358 (I) "TILDE" is defined on line 271 of
/usr/include/sys/ioctl.h.
"strnlen.c", line 37.7: 1506-356 (W) Compilation unit is empty.
"/usr/include/syms.h", line 290.9: 1506-236 (W) Macro name T_NULL has been
redefined.
"/usr/include/syms.h", line 290.9: 1506-358 (I) "T_NULL" is defined on line
150 of /usr/include/arpa/onameser_compat.h.
ar: Creating an archive file libopenbsd-compat.a.
"ssh-pkcs11.c", line 570.30: 1506-068 (W) Operation between types "unsigned
long(*)(struct _CK_FUNCTION_LIST**)" and "void*" is not allowed.
ar: Creating an archive file libssh.a.
    1500-030: (I) INFORMATION: main: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater
than 8192.
    1500-030: (I) INFORMATION: process_config_line: Additional optimization
may be attained by recompiling and specifying MAXMEM option with a value
greater than 8192.
    1500-030: (I) INFORMATION: main: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater
than 8192.
"auth-rsa.c", line 220.44: 1506-280 (W) Function argument assignment
between types "unsigned int*" and "int*" is not allowed.
"platform.c", line 195.44: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
    1500-030: (I) INFORMATION: process_server_config_line: Additional
optimization may be attained by recompiling and specifying MAXMEM option
with a value greater than 8192.
"monitor.c", line 702.36: 1506-280 (W) Function argument assignment between
types "unsigned int*" and "int*" is not allowed.
     470  1500-010: (W) WARNING in monitor_child_postauth: Infinite loop.
Program may not stop.
    1641  1500-010: (W) WARNING in sftp_server_main: Infinite loop.
Program may not stop.
     307  1500-010: (W) WARNING in main: Infinite loop.  Program may not
stop.
    1372  1500-010: (W) WARNING in main: Infinite loop.  Program may not
stop.

From djm at mindrot.org  Sun Mar  1 03:06:38 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 1 Mar 2015 03:06:38 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <54F1AC50.7040906@jupiterrise.com>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <54F0FAC8.3060806@jupiterrise.com>
 <alpine.BSO.2.11.1502281053030.11205@natsu.mindrot.org>
 <54F1AC50.7040906@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1503010306250.5891@natsu.mindrot.org>

On Sat, 28 Feb 2015, Tom G. Christensen wrote:

> Perhaps I should have been more clear but the above error is from the 'prep'
> target while it looks like you changed the 'unit' target instead.

Sorry - applied.

-d

From doctor at doctor.nl2k.ab.ca  Sun Mar  1 03:08:15 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sat, 28 Feb 2015 09:08:15 -0700
Subject: SAP-2015-3-1 issues
Message-ID: <20150228160815.GA16450@doctor.nl2k.ab.ca>

BSD/OS issues

with 1.0.2a dev

make tests

[ -d `pwd`/regress ] || mkdir -p `pwd`/regress
[ -d `pwd`/regress/unittests ] || mkdir -p `pwd`/regress/unittests
[ -d `pwd`/regress/unittests/test_helper ] ||  mkdir -p `pwd`/regress/unittests/test_helper
[ -d `pwd`/regress/unittests/sshbuf ] ||  mkdir -p `pwd`/regress/unittests/sshbuf
[ -d `pwd`/regress/unittests/sshkey ] ||  mkdir -p `pwd`/regress/unittests/sshkey
[ -d `pwd`/regress/unittests/bitmap ] ||  mkdir -p `pwd`/regress/unittests/bitmap
[ -d `pwd`/regress/unittests/hostkeys ] ||  mkdir -p `pwd`/regress/unittests/hostkeys
[ -d `pwd`/regress/unittests/kex ] ||  mkdir -p `pwd`/regress/unittests/kex
[ -f `pwd`/regress/Makefile ] ||  ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile
(cd openbsd-compat && make)
/usr/bin/ar rv libssh.a ssh_api.o  ssherr.o  sshbuf.o  sshkey.o  sshbuf-getput-basic.o  sshbuf-misc.o  sshbuf-getput-crypto.o  krl.o  bitmap.o  authfd.o authfile.o bufaux.o bufbn.o bufec.o buffer.o  canohost.o channels.o cipher.o cipher-aes.o cipher-aesctr.o  cipher-bf1.o cipher-ctr.o cipher-3des1.o cleanup.o  compat.o crc32.o deattack.o fatal.o hostfile.o  log.o match.o md-sha256.o moduli.o nchan.o packet.o opacket.o  readpass.o rsa.o ttymodes.o xmalloc.o addrmatch.o  atomicio.o key.o dispatch.o mac.o uidswap.o uuencode.o misc.o  monitor_fdpass.o rijndael.o ssh-dss.o ssh-ecdsa.o ssh-rsa.o dh.o  msg.o progressmeter.o dns.o entropy.o gss-genr.o umac.o umac128.o  ssh-pkcs11.o smult_curve25519_ref.o  poly1305.o chacha.o cipher-chachapoly.o  ssh-ed25519.o digest-openssl.o digest-libc.o hmac.o  sc25519.o ge25519.o fe25519.o ed25519.o verify.o hash.o blocks.o  kex.o kexdh.o kexgex.o kexecdh.o kexc25519.o  kexdhc.o kexgexc.o kexecdhc.o kexc25519c.o  kexdhs.o kexgexs.o kexecdhs.o kexc25519s.o
r - ssh_api.o
r - ssherr.o
r - sshbuf.o
r - sshkey.o
r - sshbuf-getput-basic.o
r - sshbuf-misc.o
r - sshbuf-getput-crypto.o
r - krl.o
r - bitmap.o
r - authfd.o
r - authfile.o
r - bufaux.o
r - bufbn.o
r - bufec.o
r - buffer.o
r - canohost.o
r - channels.o
r - cipher.o
r - cipher-aes.o
r - cipher-aesctr.o
r - cipher-bf1.o
r - cipher-ctr.o
r - cipher-3des1.o
r - cleanup.o
r - compat.o
r - crc32.o
r - deattack.o
r - fatal.o
r - hostfile.o
r - log.o
r - match.o
r - md-sha256.o
r - moduli.o
r - nchan.o
r - packet.o
r - opacket.o
r - readpass.o
r - rsa.o
r - ttymodes.o
r - xmalloc.o
r - addrmatch.o
r - atomicio.o
r - key.o
r - dispatch.o
r - mac.o
r - uidswap.o
r - uuencode.o
r - misc.o
r - monitor_fdpass.o
r - rijndael.o
r - ssh-dss.o
r - ssh-ecdsa.o
r - ssh-rsa.o
r - dh.o
r - msg.o
r - progressmeter.o
r - dns.o
r - entropy.o
r - gss-genr.o
r - umac.o
r - umac128.o
r - ssh-pkcs11.o
r - smult_curve25519_ref.o
r - poly1305.o
r - chacha.o
r - cipher-chachapoly.o
r - ssh-ed25519.o
r - digest-openssl.o
r - digest-libc.o
r - hmac.o
r - sc25519.o
r - ge25519.o
r - fe25519.o
r - ed25519.o
r - verify.o
r - hash.o
r - blocks.o
r - kex.o
r - kexdh.o
r - kexgex.o
r - kexecdh.o
r - kexc25519.o
r - kexdhc.o
r - kexgexc.o
r - kexecdhc.o
r - kexc25519c.o
r - kexdhs.o
r - kexgexs.o
r - kexecdhs.o
r - kexc25519s.o
ranlib libssh.a
/usr/bin/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/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat  -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o  audit.o audit-bsm.o audit-linux.o platform.o  sshpty.o sshlogin.o servconf.o serverloop.o  auth.o auth1.o auth2.o auth-options.o session.o  auth-chall.o auth2-chall.o groupaccess.o  auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o  auth2-none.o auth2-passwd.o auth2-pubkey.o  monitor_mm.o monitor.o monitor_wrap.o auth-krb5.o  auth2-gss.o gss-serv.o gss-serv-krb5.o  loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o  sftp-server.o sftp-common.o  roaming_common.o roaming_serv.o  sandbox-null.o sandbox-rlimit.o sandbox-systrace.o sandbox-darwin.o  sandbox-seccomp-filter.o sandbox-capsicum.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat  -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-add ssh-add.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keyscan ssh-keyscan.o roaming_dummy.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keysign ssh-keysign.o readconf.o roaming_dummy.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-pkcs11-helper ssh-pkcs11-helper.o ssh-pkcs11.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-agent ssh-agent.o ssh-pkcs11-client.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o scp scp.o progressmeter.o bufaux.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sftp-server sftp-server.o sftp-common.o sftp-server-main.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sftp progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -g -O2 -Wall  -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -I. -I. -I/usr/contrib//include  -DSSHDIR=\"/etc\"  -D_PATH_SSH_PROGRAM=\"/usr/contrib/bin/ssh\"  -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/contrib/libexec/ssh-askpass\"  -D_PATH_SFTP_SERVER=\"/usr/contrib/libexec/sftp-server\"  -D_PATH_SSH_KEY_SIGN=\"/usr/contrib/libexec/ssh-keysign\"  -D_PATH_SSH_PKCS11_HELPER=\"/usr/contrib/libexec/ssh-pkcs11-helper\"  -D_PATH_SSH_PIDDIR=\"/var/run\"  -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -o regress/modpipe ./regress/modpipe.c  -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -g -O2 -Wall  -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -I. -I. -I/usr/contrib//include  -DSSHDIR=\"/etc\"  -D_PATH_SSH_PROGRAM=\"/usr/contrib/bin/ssh\"  -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/contrib/libexec/ssh-askpass\"  -D_PATH_SFTP_SERVER=\"/usr/contrib/libexec/sftp-server\"  -D_PATH_SSH_KEY_SIGN=\"/usr/contrib/libexec/ssh-keysign\"  -D_PATH_SSH_PKCS11_HELPER=\"/usr/contrib/libexec/ssh-pkcs11-helper\"  -D_PATH_SSH_PIDDIR=\"/var/run\"  -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -o regress/setuid-allowed ./regress/setuid-allowed.c  -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -g -O2 -Wall  -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -I. -I. -I/usr/contrib//include  -DSSHDIR=\"/etc\"  -D_PATH_SSH_PROGRAM=\"/usr/contrib/bin/ssh\"  -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/contrib/libexec/ssh-askpass\"  -D_PATH_SFTP_SERVER=\"/usr/contrib/libexec/sftp-server\"  -D_PATH_SSH_KEY_SIGN=\"/usr/contrib/libexec/ssh-keysign\"  -D_PATH_SSH_PKCS11_HELPER=\"/usr/contrib/libexec/ssh-pkcs11-helper\"  -D_PATH_SSH_PIDDIR=\"/var/run\"  -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -o regress/netcat ./regress/netcat.c  -L. -Lopenbsd-compat/ -L/usr/contrib//lib -L /usr/lib -L /usr/contrib/lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
regress/netcat.c: In function `main':
regress/netcat.c:272: warning: null format string
regress/netcat.c:345: warning: implicit declaration of function `strlcpy'
regress/netcat.c:407: warning: null format string
regress/netcat.c: In function `unix_bind':
regress/netcat.c:555: warning: comparison between signed and unsigned
regress/netcat.c: In function `unix_connect':
regress/netcat.c:591: warning: comparison between signed and unsigned
regress/netcat.c: In function `remote_connect':
regress/netcat.c:656: `on' undeclared (first use in this function)
regress/netcat.c:656: (Each undeclared identifier is reported only once
regress/netcat.c:656: for each function it appears in.)
regress/netcat.c: In function `local_listen':
regress/netcat.c:765: warning: null format string
regress/netcat.c: In function `build_ports':
regress/netcat.c:1140: warning: null format string
regress/netcat.c:1163: warning: null format string
regress/netcat.c: In function `set_common_sockopts':
regress/netcat.c:1201: warning: null format string
regress/netcat.c: In function `decode_addrport':
regress/netcat.c:1423: warning: comparison between signed and unsigned
*** Error code 1

Stop.

I did briefly install this and got on Tera Term

Unexpected SSH2 message(80) on current stage (6) .

FYI

I might test this later on FreeBSD 10.1 amd64 using curent openssl 1.0.2a dev


-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
The body says what words cannot.  -Martha Graham

From djm at mindrot.org  Sun Mar  1 03:23:04 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 1 Mar 2015 03:23:04 +1100 (AEDT)
Subject: SAP-2015-3-1 issues
In-Reply-To: <20150228160815.GA16450@doctor.nl2k.ab.ca>
References: <20150228160815.GA16450@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.11.1503010316360.5891@natsu.mindrot.org>



On Sat, 28 Feb 2015, The Doctor wrote:

> BSD/OS issues
> 
> with 1.0.2a dev

Thanks for testing.

> make tests
> 
> regress/netcat.c:656: `on' undeclared (first use in this function)
> regress/netcat.c:656: (Each undeclared identifier is reported only once
> regress/netcat.c:656: for each function it appears in.)
> regress/netcat.c: In function `local_listen':
> regress/netcat.c:765: warning: null format string
> regress/netcat.c: In function `build_ports':
> regress/netcat.c:1140: warning: null format string
> regress/netcat.c:1163: warning: null format string

I've fixed these (see diff below)

> I did briefly install this and got on Tera Term
> 
> Unexpected SSH2 message(80) on current stage (6) .

Is this an error that breaks the connection or a warning?

-d

From djm at mindrot.org  Sun Mar  1 03:23:45 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 1 Mar 2015 03:23:45 +1100 (AEDT)
Subject: SAP-2015-3-1 issues
In-Reply-To: <alpine.BSO.2.11.1503010316360.5891@natsu.mindrot.org>
References: <20150228160815.GA16450@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1503010316360.5891@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1503010323210.5891@natsu.mindrot.org>

On Sun, 1 Mar 2015, Damien Miller wrote:

> I've fixed these (see diff below)

The actual diff:


diff --git regress/netcat.c regress/netcat.c
index 29e85bf..f8fc7ee 100644
--- regress/netcat.c
+++ regress/netcat.c
@@ -269,7 +269,7 @@ main(int argc, char *argv[])
 		case 'x':
 			xflag = 1;
 			if ((proxy = strdup(optarg)) == NULL)
-				err(1, NULL);
+				errx(1, "strdup");
 			break;
 		case 'z':
 			zflag = 1;
@@ -404,7 +404,7 @@ main(int argc, char *argv[])
 			if (family != AF_UNIX)
 				s = local_listen(host, uport, hints);
 			if (s < 0)
-				err(1, NULL);
+				err(1, "local_listen");
 			/*
 			 * For UDP and -k, don't connect the socket, let it
 			 * receive datagrams from multiple socket pairs.
@@ -629,7 +629,7 @@ remote_connect(const char *host, const char *port, struct addrinfo hints)
 {
 	struct addrinfo *res, *res0;
 	int s, error;
-#ifdef SO_RTABLE
+#if defined(SO_RTABLE) || defined(SO_BINDANY)
 	int on = 1;
 #endif
 
@@ -762,7 +762,7 @@ local_listen(char *host, char *port, struct addrinfo hints)
 #ifdef SO_REUSEPORT
 		ret = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof(x));
 		if (ret == -1)
-			err(1, NULL);
+			err(1, "setsockopt");
 #endif
 		set_common_sockopts(s);
 
@@ -1137,7 +1137,7 @@ build_ports(char *p)
 		for (cp = lo; cp <= hi; cp++) {
 			portlist[x] = calloc(1, PORT_MAX_LEN);
 			if (portlist[x] == NULL)
-				err(1, NULL);
+				errx(1, "calloc");
 			snprintf(portlist[x], PORT_MAX_LEN, "%d", cp);
 			x++;
 		}
@@ -1160,7 +1160,7 @@ build_ports(char *p)
 			errx(1, "port number %s: %s", errstr, p);
 		portlist[0] = strdup(p);
 		if (portlist[0] == NULL)
-			err(1, NULL);
+			errx(1, "strdup");
 	}
 }
 
@@ -1192,13 +1192,13 @@ set_common_sockopts(int s)
 	if (Sflag) {
 		if (setsockopt(s, IPPROTO_TCP, TCP_MD5SIG,
 			&x, sizeof(x)) == -1)
-			err(1, NULL);
+			err(1, "setsockopt");
 	}
 #endif
 	if (Dflag) {
 		if (setsockopt(s, SOL_SOCKET, SO_DEBUG,
 			&x, sizeof(x)) == -1)
-			err(1, NULL);
+			err(1, "setsockopt");
 	}
 	if (Tflag != -1) {
 		if (setsockopt(s, IPPROTO_IP, IP_TOS,

From aixtools at gmail.com  Sun Mar  1 04:05:34 2015
From: aixtools at gmail.com (Michael Felt)
Date: Sat, 28 Feb 2015 18:05:34 +0100
Subject: SNAP-20150301 compiler messages on AIX
In-Reply-To: <CANvxniXQWfv+6yp=vDyvOaFTAicxCjW60Vesm2x4E=kJ4EZ7eQ@mail.gmail.com>
References: <CANvxniXQWfv+6yp=vDyvOaFTAicxCjW60Vesm2x4E=kJ4EZ7eQ@mail.gmail.com>
Message-ID: <CANvxniVkyKF3ssE-skfXjmvqpmxsYWug8ha27twZB91V+qX_Wg@mail.gmail.com>

Now with gcc:
root at x065:[/]gcc --version
gcc (GCC) 4.7.4
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I see you are adding warnings for blibpath :)

root at x065:[/data/prj/openbsd/openssh/snap/opensshRC-6.8]buildaix
gcc is /opt/bin/gcc
+ CPPFLAGS="-I/opt/include" CFLAGS="-I/opt/aixtools/include -O2"
./configure \
                --prefix=/opt  \
                --sysconfdir=/var/opensshRC/etc \
                --sharedstatedir=/var/opensshRC/com \
                --localstatedir=/var/opensshRC \
                --mandir=/usr/share/man \
                --infodir=/opt/share/info/opensshRC  \
                        > build/aix/configure.out
configure: WARNING: zlib.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: zlib.h: proceeding with the compiler's result
configure: WARNING: Please check and edit blibpath in LDFLAGS in Makefile
+ /opt/bin/make > build/aix/make.out
arc4random.c: In function 'arc4random_uniform':
arc4random.c:299:3: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
glob.c:93:0: warning: "TILDE" redefined [enabled by default]
In file included from ../openbsd-compat/openbsd-compat.h:196:0,
                 from ../includes.h:177,
                 from glob.c:61:
/usr/include/sys/ioctl.h:250:0: note: this is the location of the previous
definition
realpath.c: In function 'realpath':
realpath.c:93:16: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
realpath.c:172:19: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
ar: Creating an archive file libopenbsd-compat.a.
sshkey.c: In function 'sshkey_certify':
sshkey.c:2426:2: warning: implicit declaration of function 'arc4random_buf'
[-Wimplicit-function-declaration]
sshkey.c: In function 'sshkey_private_to_blob2':
sshkey.c:3120:2: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
channels.c: In function 'channel_post_mux_listener':
channels.c:1973:2: warning: implicit declaration of function 'getpeereid'
[-Wimplicit-function-declaration]
channels.c: In function 'x11_request_forwarding_with_spoofing':
channels.c:4224:5: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
hostfile.c: In function 'host_hash':
hostfile.c:133:4: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
packet.c: In function 'ssh_packet_send1':
packet.c:867:3: warning: implicit declaration of function 'arc4random_buf'
[-Wimplicit-function-declaration]
packet.c: In function 'ssh_packet_send_ignore':
packet.c:2195:4: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
packet.c: In function 'ssh_packet_need_rekeying':
packet.c:2218:26: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
misc.c: In function 'bandwidth_limit':
misc.c:946:2: warning: suggest parentheses around '&&' within '||'
[-Wparentheses]
ed25519.c: In function 'crypto_sign_ed25519_keypair':
ed25519.c:36:3: warning: implicit declaration of function 'arc4random_buf'
[-Wimplicit-function-declaration]
kex.c: In function 'kex_send_kexinit':
kex.c:306:2: warning: implicit declaration of function 'arc4random_buf'
[-Wimplicit-function-declaration]
kexc25519.c: In function 'kexc25519_keygen':
kexc25519.c:58:2: warning: implicit declaration of function
'arc4random_buf' [-Wimplicit-function-declaration]
ar: Creating an archive file libssh.a.
clientloop.c: In function 'client_x11_get_proto':
clientloop.c:415:5: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
sshconnect1.c: In function 'ssh_kex':
sshconnect1.c:566:4: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
roaming_client.c: In function 'roaming_resume':
roaming_client.c:151:4: warning: implicit declaration of function
'arc4random' [-Wimplicit-function-declaration]
sshd.c: In function 'generate_ephemeral_server_key':
sshd.c:395:2: warning: implicit declaration of function 'arc4random_buf'
[-Wimplicit-function-declaration]
platform.c: In function 'platform_krb5_get_principal_name':
platform.c:195:2: warning: passing argument 1 of
'aix_krb5_get_principal_name' discards 'const' qualifier from pointer
target type [enabled by default]
In file included from openbsd-compat/openbsd-compat.h:271:0,
                 from includes.h:177,
                 from platform.c:19:
openbsd-compat/port-aix.h:100:7: note: expected 'char *' but argument is of
type 'const char *'
sshlogin.c: In function 'store_lastlog_message':
sshlogin.c:92:9: warning: unused variable 'last_login_time'
[-Wunused-variable]
sshlogin.c:91:53: warning: unused variable 'buf' [-Wunused-variable]
sshlogin.c:91:21: warning: unused variable 'hostname' [-Wunused-variable]
ld: 0711-224 WARNING: Duplicate symbol: active_state
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-224 WARNING: Duplicate symbol: active_state
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ssh-keysign.c: In function 'main':
ssh-keysign.c:225:2: warning: implicit declaration of function
'arc4random_buf' [-Wimplicit-function-declaration]
ld: 0711-224 WARNING: Duplicate symbol: active_state
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-224 WARNING: Duplicate symbol: active_state
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ssh-agent.c: In function 'after_select':
ssh-agent.c:1034:5: warning: implicit declaration of function 'getpeereid'
[-Wimplicit-function-declaration]



On Sat, Feb 28, 2015 at 4:43 PM, Michael Felt <aixtools at gmail.com> wrote:

> This is compiling on AIX with XL C, v11, patch 020
> michael at x071:[/home/michael]xlc -qversion
> IBM XL C/C++ for AIX, V11.1 (5724-X13)
> Version: 11.01.0000.0020
>
> "bsd-cray.c", line 817.23: 1506-356 (W) Compilation unit is empty.
> "kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
> "glob.c", line 93.9: 1506-236 (W) Macro name TILDE has been redefined.
> "glob.c", line 93.9: 1506-358 (I) "TILDE" is defined on line 271 of
> /usr/include/sys/ioctl.h.
> "strnlen.c", line 37.7: 1506-356 (W) Compilation unit is empty.
> "/usr/include/syms.h", line 290.9: 1506-236 (W) Macro name T_NULL has been
> redefined.
> "/usr/include/syms.h", line 290.9: 1506-358 (I) "T_NULL" is defined on
> line 150 of /usr/include/arpa/onameser_compat.h.
> ar: Creating an archive file libopenbsd-compat.a.
> "ssh-pkcs11.c", line 570.30: 1506-068 (W) Operation between types
> "unsigned long(*)(struct _CK_FUNCTION_LIST**)" and "void*" is not allowed.
> ar: Creating an archive file libssh.a.
>     1500-030: (I) INFORMATION: main: Additional optimization may be
> attained by recompiling and specifying MAXMEM option with a value greater
> than 8192.
>     1500-030: (I) INFORMATION: process_config_line: Additional
> optimization may be attained by recompiling and specifying MAXMEM option
> with a value greater than 8192.
>     1500-030: (I) INFORMATION: main: Additional optimization may be
> attained by recompiling and specifying MAXMEM option with a value greater
> than 8192.
> "auth-rsa.c", line 220.44: 1506-280 (W) Function argument assignment
> between types "unsigned int*" and "int*" is not allowed.
> "platform.c", line 195.44: 1506-280 (W) Function argument assignment
> between types "char*" and "const char*" is not allowed.
>     1500-030: (I) INFORMATION: process_server_config_line: Additional
> optimization may be attained by recompiling and specifying MAXMEM option
> with a value greater than 8192.
> "monitor.c", line 702.36: 1506-280 (W) Function argument assignment
> between types "unsigned int*" and "int*" is not allowed.
>      470  1500-010: (W) WARNING in monitor_child_postauth: Infinite loop.
> Program may not stop.
>     1641  1500-010: (W) WARNING in sftp_server_main: Infinite loop.
> Program may not stop.
>      307  1500-010: (W) WARNING in main: Infinite loop.  Program may not
> stop.
>     1372  1500-010: (W) WARNING in main: Infinite loop.  Program may not
> stop.
>
>

From doctor at doctor.nl2k.ab.ca  Sun Mar  1 07:16:29 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sat, 28 Feb 2015 13:16:29 -0700
Subject: SAP-2015-3-1 issues
In-Reply-To: <alpine.BSO.2.11.1503010316360.5891@natsu.mindrot.org>
References: <20150228160815.GA16450@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1503010316360.5891@natsu.mindrot.org>
Message-ID: <20150228201628.GA2032@doctor.nl2k.ab.ca>

On Sun, Mar 01, 2015 at 03:23:04AM +1100, Damien Miller wrote:
> 
> 
> On Sat, 28 Feb 2015, The Doctor wrote:
> 
> > BSD/OS issues
> > 
> > with 1.0.2a dev
> 
> Thanks for testing.
> 

You are welcome.

> > make tests
> > 
> > regress/netcat.c:656: `on' undeclared (first use in this function)
> > regress/netcat.c:656: (Each undeclared identifier is reported only once
> > regress/netcat.c:656: for each function it appears in.)
> > regress/netcat.c: In function `local_listen':
> > regress/netcat.c:765: warning: null format string
> > regress/netcat.c: In function `build_ports':
> > regress/netcat.c:1140: warning: null format string
> > regress/netcat.c:1163: warning: null format string
> 
> I've fixed these (see diff below)
>

When will it be added in?
 
> > I did briefly install this and got on Tera Term
> > 
> > Unexpected SSH2 message(80) on current stage (6) .
> 
> Is this an error that breaks the connection or a warning?

Break the connection; in this case Tera Type.

> 
> -d

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
The body says what words cannot.  -Martha Graham

From djm at mindrot.org  Sun Mar  1 19:54:13 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 1 Mar 2015 19:54:13 +1100 (AEDT)
Subject: SAP-2015-3-1 issues
In-Reply-To: <20150228201628.GA2032@doctor.nl2k.ab.ca>
References: <20150228160815.GA16450@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1503010316360.5891@natsu.mindrot.org>
 <20150228201628.GA2032@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.11.1503011950390.24860@natsu.mindrot.org>

On Sat, 28 Feb 2015, The Doctor wrote:

> When will it be added in?

It's already committed. It's in git now and will be in the next snapshot.

> > Is this an error that breaks the connection or a warning?
> 
> Break the connection; in this case Tera Type.

It seems to be crashing on a valid, but unexpected extension message, do
you know what identification tera type sends in its ssh banner?

You can find out by connecting to sshd running in debug mode or
by connecting to a listening netcat. E.g.

nc -l 2222

and connect to your host on port 2222.

-d

From djm at mindrot.org  Tue Mar  3 07:50:32 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 3 Mar 2015 07:50:32 +1100 (AEDT)
Subject: bugzilla updated, migrated from bzr => git
Message-ID: <alpine.BSO.2.11.1503030748250.14039@natsu.mindrot.org>

Hi,

I just updated bugzilla.mindrot.org to the latest upstream version
(4.4.8). Upstream migrated from bzr to git too, so I've jumped that
shark^wchange too.

Let me know if you run into any problems.

-d

From e.j.rietveld at gmail.com  Tue Mar  3 08:50:32 2015
From: e.j.rietveld at gmail.com (Emanuel Rietveld)
Date: Mon, 2 Mar 2015 22:50:32 +0100
Subject: Unable to use ssh-agent with confirmation, when logged in on a
 virtual terminal
Message-ID: <CAC3xr8p222Efy3VG+ieBrU=RNnwzYd07sSgmv_0Rd72ib-3JjQ@mail.gmail.com>

>I mostly found this option mentioned in connection with agent forwarding,
and that's  use  case I have.
>
>The benefit being that no one can use the 'forwarded' key/identity, unless
I confirm it. So me forwarding my identity to a server getting hacked does
not  compromise security.

I'm using the below script to prompt for confirmation when agent
forwarding. Please keep in mind the following disclaimer: I don't really
know what I'm doing. It works for me, but I don't fully understand all the
moving parts and that it works *for now* could just be a happy accident.

#!/bin/bash
set -o errexit
set -o nounset

# This script is useful when forwarding your agent to an untrusted
server. It works without X.
#
# To use this script, export DISPLAY=FAKE
SSH_ASKPASS=/path/to/this/script SSH_ASKPASS_TTY=$(tty)
# before you do eval `ssh-agent` (these variables should end up in the
environment ssh-agent runs in)
# Then add keys to the agent with ssh-add -c /path/to/key
# ssh-agent will then call this script to ask you for confirmation
when asked for that key.
#
# DISPLAY and SSH_ASKPASS must be set so this script will be called at
all. Once we're in this script,
# it is not clear what terminal we should ask for confirmation on,
since ssh-agent detaches from the tty.
# That's why we pass the tty in as an environment variable as well.

# Connect stdin, stdout, and stderr to the tty
exec 0<"$SSH_ASKPASS_TTY"
exec 1>"$SSH_ASKPASS_TTY"
exec 2>"$SSH_ASKPASS_TTY"

# We're most likely being called when the tty is already in used by
ssh, which changes tty settings.
# First set the tty to something sane, so we can ask for confirmation.
original_tty_settings=$(stty -g)
stty sane

# $@ is passed in from ssh-agent, and includes which key is being requested.
echo "$@"
# 5 second timeout
read -t5 answer

# Restore the tty settings that ssh was using.
stty "$original_tty_settings"

# Zero exit status means we approve this authentication request.
if [[ "$answer" == "y" ]]; then
  exit 0
fi

exit 1

From gibsonmic at gmail.com  Tue Mar  3 16:11:54 2015
From: gibsonmic at gmail.com (John Dow)
Date: Tue, 3 Mar 2015 10:11:54 +0500
Subject: Building for CygWin without OpenSSL fails
Message-ID: <CAG=vBo0i4+BbRR2ZcCovOAqiPHd-DNJY6jBe_GAXdvM_hTqPgg@mail.gmail.com>

Hello everyone,

I tried to build OpenSSH on Windows (CygWin) with make OPENSSL=no but it
still
requires openSSL header files and libraries. Looks lik? CygWin is not
supported for this configuration.

I wanted to test the version with only DJB's primitives and failed to
do that. Can you please help?

From djm at mindrot.org  Tue Mar  3 17:46:43 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 3 Mar 2015 17:46:43 +1100 (AEDT)
Subject: Building for CygWin without OpenSSL fails
In-Reply-To: <CAG=vBo0i4+BbRR2ZcCovOAqiPHd-DNJY6jBe_GAXdvM_hTqPgg@mail.gmail.com>
References: <CAG=vBo0i4+BbRR2ZcCovOAqiPHd-DNJY6jBe_GAXdvM_hTqPgg@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503031746100.27111@natsu.mindrot.org>

On Tue, 3 Mar 2015, John Dow wrote:

> Hello everyone,
> 
> I tried to build OpenSSH on Windows (CygWin) with make OPENSSL=no but it
> still
> requires openSSL header files and libraries. Looks lik? CygWin is not
> supported for this configuration.

Could you please post a full build log, including configure and the
options you called it with?

-d

From gibsonmic at gmail.com  Tue Mar  3 18:35:41 2015
From: gibsonmic at gmail.com (John Dow)
Date: Tue, 3 Mar 2015 12:35:41 +0500
Subject: Building for CygWin without OpenSSL fails
Message-ID: <CAEKRuG5zw4v5OqF6_3CKh7wzg7yVUACziLmeUdmKPjjmLN2MaA@mail.gmail.com>

./configure > configure.log
https://www.dropbox.com/s/qgosxm73wdt7jhx/configure.log?dl=0

make OPENSSL=no > make.log
https://www.dropbox.com/s/o7d5d3lu3jrfhxd/make.log?dl=0



2015-03-03 11:46 GMT+05:00 Damien Miller <djm at mindrot.org>:
> On Tue, 3 Mar 2015, John Dow wrote:
>
>> Hello everyone,
>>
>> I tried to build OpenSSH on Windows (CygWin) with make OPENSSL=no but it
>> still
>> requires openSSL header files and libraries. Looks lik? CygWin is not
>> supported for this configuration.
>
> Could you please post a full build log, including configure and the
> options you called it with?
>
> -d

From openssh at roumenpetrov.info  Tue Mar  3 23:28:34 2015
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Tue, 03 Mar 2015 14:28:34 +0200
Subject: configure and have crypt or DES_crypt
Message-ID: <54F5A8F2.2000100@roumenpetrov.info>

Hello,

With current portable master source tree HAVE_CRYPT and HAVE_DES_CRYPT 
are not defined.
It seems to me this is regression introduced with implementation of 
configure options --with-openssl.

Impacted code is in xcrypt.c:
...
# if defined(WITH_OPENSSL) && !defined(HAVE_CRYPT) && 
defined(HAVE_DES_CRYPT)
#  include <openssl/des.h>
#  define crypt DES_crypt
# endif
...

Only above preprocessor statement use defines HAVE_CRYPT and HAVE_DES_CRYPT.


Configure script look like (
if with OpenSSL then
   ....
else
   ...
   AC_CHECK_FUNCS([crypt DES_crypt])
fi

Proposed patch restore previous behavior.


Regards,
Roumen Petrov

-- 
Get SSH with X.509 certificate support
http://roumenpetrov.info/openssh/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-configure.ac-rewrite-check-for-functions-crypt-and-D.patch
Type: text/x-diff
Size: 971 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150303/62b8fd22/attachment.bin>

From alex at alex.org.uk  Tue Mar  3 23:56:26 2015
From: alex at alex.org.uk (Alex Bligh)
Date: Tue, 3 Mar 2015 12:56:26 +0000
Subject: Building for CygWin without OpenSSL fails
In-Reply-To: <CAEKRuG5zw4v5OqF6_3CKh7wzg7yVUACziLmeUdmKPjjmLN2MaA@mail.gmail.com>
References: <CAEKRuG5zw4v5OqF6_3CKh7wzg7yVUACziLmeUdmKPjjmLN2MaA@mail.gmail.com>
Message-ID: <EC9982C2-74BD-4E7E-8BD6-0CF02DCE6631@alex.org.uk>

John,

On 3 Mar 2015, at 07:35, John Dow <gibsonmic at gmail.com> wrote:

> ./configure > configure.log
> https://www.dropbox.com/s/qgosxm73wdt7jhx/configure.log?dl=0
> 
> make OPENSSL=no > make.log
> https://www.dropbox.com/s/o7d5d3lu3jrfhxd/make.log?dl=0

I know nothing about CygWin building, but you might want to try

./configure --without-openssl
make


-- 
Alex Bligh





From gibsonmic at gmail.com  Wed Mar  4 00:43:02 2015
From: gibsonmic at gmail.com (John Dow)
Date: Tue, 3 Mar 2015 18:43:02 +0500
Subject: Building for CygWin without OpenSSL fails
Message-ID: <CAEKRuG7POow5GYGhjKR3OFYX51tE7oDOw2xSk086pCzsnJBnOg@mail.gmail.com>

Already tried that. It says

configure: WARNING: unrecognized options: --without-openssl

2015-03-03 17:56 GMT+05:00 Alex Bligh <alex at alex.org.uk>:
> John,
>
> On 3 Mar 2015, at 07:35, John Dow <gibsonmic at gmail.com> wrote:
>
>> ./configure > configure.log
>> https://www.dropbox.com/s/qgosxm73wdt7jhx/configure.log?dl=0
>>
>> make OPENSSL=no > make.log
>> https://www.dropbox.com/s/o7d5d3lu3jrfhxd/make.log?dl=0
>
> I know nothing about CygWin building, but you might want to try
>
> ./configure --without-openssl
> make
>
>
> --
> Alex Bligh
>
>
>
>

From vinschen at redhat.com  Wed Mar  4 00:57:05 2015
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 3 Mar 2015 14:57:05 +0100
Subject: Building for CygWin without OpenSSL fails
In-Reply-To: <CAEKRuG7POow5GYGhjKR3OFYX51tE7oDOw2xSk086pCzsnJBnOg@mail.gmail.com>
References: <CAEKRuG7POow5GYGhjKR3OFYX51tE7oDOw2xSk086pCzsnJBnOg@mail.gmail.com>
Message-ID: <20150303135705.GQ3213@calimero.vinschen.de>

On Mar  3 18:43, John Dow wrote:
> Already tried that. It says
> 
> configure: WARNING: unrecognized options: --without-openssl
> 
> 2015-03-03 17:56 GMT+05:00 Alex Bligh <alex at alex.org.uk>:
> > John,
> >
> > On 3 Mar 2015, at 07:35, John Dow <gibsonmic at gmail.com> wrote:
> >
> >> ./configure > configure.log
> >> https://www.dropbox.com/s/qgosxm73wdt7jhx/configure.log?dl=0
> >>
> >> make OPENSSL=no > make.log
> >> https://www.dropbox.com/s/o7d5d3lu3jrfhxd/make.log?dl=0
> >
> > I know nothing about CygWin building, but you might want to try
> >
> > ./configure --without-openssl
> > make
> >
> >
> > --
> > Alex Bligh

Uhm, guys?  It's Cygwin, not CygWin.


Just saying...
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: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150303/f320c14a/attachment-0001.bin>

From doctor at doctor.nl2k.ab.ca  Wed Mar  4 02:25:56 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 3 Mar 2015 08:25:56 -0700
Subject: openssh-SNAP-20150304 issues
Message-ID: <20150303152556.GA10317@doctor.nl2k.ab.ca>


Script started on Tue Mar  3 07:35:34 2015
doctor.nl2k.ab.ca//usr/source/openssh-SNAP-20150304$ make tests
[ -d `pwd`/regress ] || mkdir -p `pwd`/regress
[ -d `pwd`/regress/unittests ] || mkdir -p `pwd`/regress/unittests
[ -d `pwd`/regress/unittests/test_helper ] ||  mkdir -p `pwd`/regress/unittests/test_helper
[ -d `pwd`/regress/unittests/sshbuf ] ||  mkdir -p `pwd`/regress/unittests/sshbuf
[ -d `pwd`/regress/unittests/sshkey ] ||  mkdir -p `pwd`/regress/unittests/sshkey
[ -d `pwd`/regress/unittests/bitmap ] ||  mkdir -p `pwd`/regress/unittests/bitmap
[ -d `pwd`/regress/unittests/hostkeys ] ||  mkdir -p `pwd`/regress/unittests/hostkeys
[ -d `pwd`/regress/unittests/kex ] ||  mkdir -p `pwd`/regress/unittests/kex
[ -f `pwd`/regress/Makefile ] ||  ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile
(cd openbsd-compat && make)
/usr/bin/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/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat  -lcrypto -ldl -lutil -lz 
/usr/bin/gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o  audit.o audit-bsm.o audit-linux.o platform.o  sshpty.o sshlogin.o servconf.o serverloop.o  auth.o auth1.o auth2.o auth-options.o session.o  auth-chall.o auth2-chall.o groupaccess.o  auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o  auth2-none.o auth2-passwd.o auth2-pubkey.o  monitor_mm.o monitor.o monitor_wrap.o auth-krb5.o  auth2-gss.o gss-serv.o gss-serv-krb5.o  loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o  sftp-server.o sftp-common.o  roaming_common.o roaming_serv.o  sandbox-null.o sandbox-rlimit.o sandbox-systrace.o sandbox-darwin.o  sandbox-seccomp-filter.o sandbox-capsicum.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat  -lcrypto -ldl -lutil -lz  
/usr/bin/gcc -o ssh-add ssh-add.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keyscan ssh-keyscan.o roaming_dummy.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keysign ssh-keysign.o readconf.o roaming_dummy.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-pkcs11-helper ssh-pkcs11-helper.o ssh-pkcs11.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-agent ssh-agent.o ssh-pkcs11-client.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o scp scp.o progressmeter.o bufaux.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sftp-server sftp-server.o sftp-common.o sftp-server-main.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sftp progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz 
/usr/bin/gcc -g -O2 -Wall  -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fno-builtin-memset -I. -I. -I/usr/contrib//include  -DSSHDIR=\"/etc\"  -D_PATH_SSH_PROGRAM=\"/usr/contrib/bin/ssh\"  -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/contrib/libexec/ssh-askpass\"  -D_PATH_SFTP_SERVER=\"/usr/contrib/libexec/sftp-server\"  -D_PATH_SSH_KEY_SIGN=\"/usr/contrib/libexec/ssh-keysign\"  -D_PATH_SSH_PKCS11_HELPER=\"/usr/contrib/libexec/ssh-pkcs11-helper\"  -D_PATH_SSH_PIDDIR=\"/var/run\"  -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c regress/unittests/test_helper/test_helper.c -o regress/unittests/test_helper/test_helper.o
regress/unittests/test_helper/test_helper.c: In function `test_data_file':
regress/unittests/test_helper/test_helper.c:177: warning: implicit declaration of function `strlcpy'
regress/unittests/test_helper/test_helper.c: At top level:
regress/unittests/test_helper/test_helper.c:196: parse error before "__unused"
*** Error code 1

Stop.
doctor.nl2k.ab.ca//usr/source/openssh-SNAP-20150304$ less regress/unittests/test 
_helper/test_helper.c
[?1h=/*      $OpenBSD: test_helper.c,v 1.5 2015/02/16 22:20:50 djm Exp $     */
/*
 * Copyright (c) 2011 Damien Miller <djm at mindrot.org>
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/* Utility functions/framework for regress tests */

#include "includes.h"

#include <sys/types.h>
#include <sys/param.h>
#include <sys/uio.h>

#include <fcntl.h>
#include <stdio.h>
#ifdef HAVE_STDINT_H
# include <stdint.h>
#endif
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <unistd.h>
#include <signal.h>

#include <openssl/bn.h>

#if defined(HAVE_STRNVIS) && defined(HAVE_VIS_H) && !defined(BROKEN_STRNVIS)
# include <vis.h>
#endif

#include "test_helper.h"
#include "atomicio.h"

#define TEST_CHECK_INT(r, pred) do {            \
                switch (pred) {                 \
                case TEST_EQ:                   \
                        if (r == 0)             \
                                return;         \
                        break;                  \
                case TEST_NE:                   \
                        if (r != 0)             \
                                return;         \
                        break;                  \
                case TEST_LT:                   \
                        if (r < 0)              \
                                return;         \
                        break;                  \
                case TEST_LE:                   \
                        if (r <= 0)             \
                                return;         \
                        break;                  \
                case TEST_GT:                   \
                        if (r > 0)              \
                                return;         \
regress/unittests/test_helper/test_helper.c                        break;                  \
                case TEST_GE:                   \
                        if (r >= 0)             \
                                return;         \
                        break;                  \
                default:                        \
                        abort();                \
                }                               \
        } while (0)

#define TEST_CHECK(x1, x2, pred) do {           \
                switch (pred) {                 \
                case TEST_EQ:                   \
                        if (x1 == x2)           \
                                return;         \
                        break;                  \
                case TEST_NE:                   \
                        if (x1 != x2)           \
                                return;         \
                        break;                  \
                case TEST_LT:                   \
                        if (x1 < x2)            \
                                return;         \
                        break;                  \
                case TEST_LE:                   \
                        if (x1 <= x2)           \
                                return;         \
                        break;                  \
                case TEST_GT:                   \
                        if (x1 > x2)            \
                                return;         \
                        break;                  \
                case TEST_GE:                   \
                        if (x1 >= x2)           \
                                return;         \
                        break;                  \
                default:                        \
                        abort();                \
                }                               \
        } while (0)

extern char *__progname;

static int verbose_mode = 0;
static int quiet_mode = 0;
static char *active_test_name = NULL;
static u_int test_number = 0;
static test_onerror_func_t *test_onerror = NULL;
static void *onerror_ctx = NULL;
static const char *data_dir = NULL;
static char subtest_info[512];

int
main(int argc, char **argv)
{
        int ch;

        /* Handle systems without __progname */
        if (__progname == NULL) {
                __progname = strrchr(argv[0], '/');
                if (__progname == NULL || __progname[1] == '\0')
                        __progname = argv[0];   
                else
                        __progname++;
                if ((__progname = strdup(__progname)) == NULL) {
                        fprintf(stderr, "strdup failed\n");
:                        exit(1);
                }
        }

        while ((ch = getopt(argc, argv, "vqd:")) != -1) {
                switch (ch) {
                case 'd':
                        data_dir = optarg;
                        break;
                case 'q':
                        verbose_mode = 0;
                        quiet_mode = 1;
                        break;
                case 'v':
                        verbose_mode = 1;
                        quiet_mode = 0;
                        break;
                default:
                        fprintf(stderr, "Unrecognised command line option\n");
                        fprintf(stderr, "Usage: %s [-v]\n", __progname);
                        exit(1);
                }
        }
        setvbuf(stdout, NULL, _IONBF, 0);
        if (!quiet_mode)
                printf("%s: ", __progname);
        if (verbose_mode)
                printf("\n");

        tests();

        if (!quiet_mode)
                printf(" %u tests ok\n", test_number);
        return 0;
}

const char *
test_data_file(const char *name)
{
        static char ret[PATH_MAX];

        if (data_dir != NULL)
                snprintf(ret, sizeof(ret), "%s/%s", data_dir, name);
        else
                strlcpy(ret, name, sizeof(ret));
        if (access(ret, F_OK) != 0) {
                fprintf(stderr, "Cannot access data file %s: %s\n",
                    ret, strerror(errno));
                exit(1);
        }
        return ret;
}

void
test_info(char *s, size_t len)
{
        snprintf(s, len, "In test %u: \"%s\"%s%s\n", test_number,
            active_test_name == NULL ? "<none>" : active_test_name,
            *subtest_info != '\0' ? " - " : "", subtest_info);
}

#ifdef SIGINFO
static void
siginfo(int unused __unused)
{
        char buf[256];
:
        test_info(buf, sizeof(buf));
        atomicio(vwrite, STDERR_FILENO, buf, strlen(buf));
}
#endif

void
test_start(const char *n)
{
        assert(active_test_name == NULL);
        assert((active_test_name = strdup(n)) != NULL);
        *subtest_info = '\0';
        if (verbose_mode)
                printf("test %u - \"%s\": ", test_number, active_test_name);
        test_number++;
#ifdef SIGINFO
        signal(SIGINFO, siginfo);
#endif
}

void
set_onerror_func(test_onerror_func_t *f, void *ctx)
{
        test_onerror = f;
        onerror_ctx = ctx;
}

void
test_done(void)
{
        *subtest_info = '\0';
        assert(active_test_name != NULL);
        free(active_test_name);
        active_test_name = NULL;
        if (verbose_mode)
                printf("OK\n");
        else if (!quiet_mode) {
                printf(".");
                fflush(stdout);
        }
}

void
test_subtest_info(const char *fmt, ...)
{
        va_list ap;

        va_start(ap, fmt);
        vsnprintf(subtest_info, sizeof(subtest_info), fmt, ap);
        va_end(ap);
}

void
ssl_err_check(const char *file, int line)
{
        long openssl_error = ERR_get_error();

        if (openssl_error == 0)
                return;

        fprintf(stderr, "\n%s:%d: uncaught OpenSSL error: %s",
            file, line, ERR_error_string(openssl_error, NULL));
        abort();
}

static const char *
:pred_name(enum test_predicate p)
{
        switch (p) {
        case TEST_EQ:
                return "EQ";
        case TEST_NE:
                return "NE";
        case TEST_LT:
                return "LT";
        case TEST_LE:
                return "LE";
        case TEST_GT:
                return "GT";
        case TEST_GE:
                return "GE";
        default:
                return "UNKNOWN";
        }
}

static void
test_die(void)
{
        if (test_onerror != NULL)
                test_onerror(onerror_ctx);
        abort();
}

static void
test_header(const char *file, int line, const char *a1, const char *a2,
    const char *name, enum test_predicate pred)
{
        fprintf(stderr, "\n%s:%d test #%u \"%s\"%s%s\n", 
            file, line, test_number, active_test_name,
            *subtest_info != '\0' ? " - " : "", subtest_info);
        fprintf(stderr, "ASSERT_%s_%s(%s%s%s) failed:\n",
            name, pred_name(pred), a1,
            a2 != NULL ? ", " : "", a2 != NULL ? a2 : "");
}

void
assert_bignum(const char *file, int line, const char *a1, const char *a2,
    const BIGNUM *aa1, const BIGNUM *aa2, enum test_predicate pred)
{
        int r = BN_cmp(aa1, aa2);

        TEST_CHECK_INT(r, pred);
        test_header(file, line, a1, a2, "BIGNUM", pred);
        fprintf(stderr, "%12s = 0x%s\n", a1, BN_bn2hex(aa1));
        fprintf(stderr, "%12s = 0x%s\n", a2, BN_bn2hex(aa2));
        test_die();
}

void
assert_string(const char *file, int line, const char *a1, const char *a2,
    const char *aa1, const char *aa2, enum test_predicate pred)
{
        int r;

        /* Verify pointers are not NULL */
        assert_ptr(file, line, a1, "NULL", aa1, NULL, TEST_NE);
        assert_ptr(file, line, a2, "NULL", aa2, NULL, TEST_NE);

        r = strcmp(aa1, aa2);
        TEST_CHECK_INT(r, pred);
        test_header(file, line, a1, a2, "STRING", pred);
:        fprintf(stderr, "%12s = %s (len %zu)\n", a1, aa1, strlen(aa1));
        fprintf(stderr, "%12s = %s (len %zu)\n", a2, aa2, strlen(aa2));
        test_die();
}

static char *
tohex(const void *_s, size_t l)
{
        u_int8_t *s = (u_int8_t *)_s;
        size_t i, j;
        const char *hex = "0123456789abcdef";
        char *r = malloc((l * 2) + 1);

        assert(r != NULL);
        for (i = j = 0; i < l; i++) {
                r[j++] = hex[(s[i] >> 4) & 0xf];
                r[j++] = hex[s[i] & 0xf];
        }
        r[j] = '\0';
        return r;
}

void
assert_mem(const char *file, int line, const char *a1, const char *a2,
    const void *aa1, const void *aa2, size_t l, enum test_predicate pred)
{
        int r;

        if (l == 0)
                return;
        /* If length is >0, then verify pointers are not NULL */
        assert_ptr(file, line, a1, "NULL", aa1, NULL, TEST_NE);
        assert_ptr(file, line, a2, "NULL", aa2, NULL, TEST_NE);

        r = memcmp(aa1, aa2, l);
        TEST_CHECK_INT(r, pred);
        test_header(file, line, a1, a2, "STRING", pred);
        fprintf(stderr, "%12s = %s (len %zu)\n", a1, tohex(aa1, MIN(l, 256)), l)
;
        fprintf(stderr, "%12s = %s (len %zu)\n", a2, tohex(aa2, MIN(l, 256)), l)
;
        test_die();
}

static int
memvalcmp(const u_int8_t *s, u_char v, size_t l, size_t *where)
{
        size_t i;

        for (i = 0; i < l; i++) {
                if (s[i] != v) {
                        *where = i;
                        return 1;
                }
        }
        return 0;
}

void
assert_mem_filled(const char *file, int line, const char *a1,
    const void *aa1, u_char v, size_t l, enum test_predicate pred)
{
        size_t where = -1;
        int r;
        char tmp[64];

:[?1l>You have new mail in /var/mail/doctor
doctor.nl2k.ab.ca//usr/source/openssh-SNAP-20150304$ exit
exit

Script done on Tue Mar  3 07:36:47 2015
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
You know everybody is ignorant, only on different subjects.  -Will Rogers

From djm at mindrot.org  Wed Mar  4 04:14:26 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 04:14:26 +1100 (AEDT)
Subject: configure and have crypt or DES_crypt
In-Reply-To: <54F5A8F2.2000100@roumenpetrov.info>
References: <54F5A8F2.2000100@roumenpetrov.info>
Message-ID: <alpine.BSO.2.11.1503040413160.6373@natsu.mindrot.org>

On Tue, 3 Mar 2015, Roumen Petrov wrote:

> Hello,
> 
> With current portable master source tree HAVE_CRYPT and HAVE_DES_CRYPT are not
> defined.
> It seems to me this is regression introduced with implementation of configure
> options --with-openssl.
...
> Proposed patch restore previous behavior.

I think that might break some systems that configure --without-openssl,
so it probably better to move the test out of the if-else entirely.

diff --git a/configure.ac b/configure.ac
index 2ef9db6..9a22539 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2710,9 +2710,10 @@ if test "x$openssl" = "xyes" ; then
 	AC_SUBST([COMMENT_OUT_ECC])
 else
 	AC_CHECK_LIB([crypt], [crypt], [LIBS="$LIBS -lcrypt"])
-	AC_CHECK_FUNCS([crypt DES_crypt])
 fi
 
+AC_CHECK_FUNCS([crypt DES_crypt])
+
 AC_CHECK_FUNCS([ \
 	arc4random \
 	arc4random_buf \


From openssh at roumenpetrov.info  Wed Mar  4 04:16:06 2015
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Tue, 03 Mar 2015 19:16:06 +0200
Subject: hostkey-rotate, grep and two line search pattern
Message-ID: <54F5EC56.3070807@roumenpetrov.info>

Hello,

Regression test hostkey-rotate .

After 'learn new primary' known_hosts contain both rsa keys - old and 
new one.
Function check_key_present use awk to get search pattern and script 
return two lines.
In such case Solaris grep command return error 41.
Simple test command:
$ grep '1
 > 2' /tmp/a
grep: RE error 41: No remembered search string.

It is reported in [1] with patch to change grep to fgrep.
As fgrep use "pattern as a list of fixed strings, separated by newlines" 
fgrep could be used to resolve issue.


I would like to propose another correction - change logic of 
check_key_present to search known_hosts for public key.
Attached file implement new search. It use 'fgrep ... > /dev/null'. Also 
'grep -q ..' works well.


Regards,
Roumen Petrov

[1] 
http://www.gossamer-threads.com/lists/openssh/dev/60908?do=post_view_threaded

-- 
Get SSH with X.509 certificate support
http://roumenpetrov.info/openssh/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-regress-hostkey-rotate.sh-rewrite-check_key_present-.patch
Type: text/x-diff
Size: 951 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150303/76eccd41/attachment-0001.bin>

From openssh at roumenpetrov.info  Wed Mar  4 04:24:11 2015
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Tue, 03 Mar 2015 19:24:11 +0200
Subject: configure and have crypt or DES_crypt
In-Reply-To: <alpine.BSO.2.11.1503040413160.6373@natsu.mindrot.org>
References: <54F5A8F2.2000100@roumenpetrov.info>
 <alpine.BSO.2.11.1503040413160.6373@natsu.mindrot.org>
Message-ID: <54F5EE3B.1050706@roumenpetrov.info>

Damien Miller wrote:
> On Tue, 3 Mar 2015, Roumen Petrov wrote:
>
>> Hello,
>>
>> With current portable master source tree HAVE_CRYPT and HAVE_DES_CRYPT are not
>> defined.
>> It seems to me this is regression introduced with implementation of configure
>> options --with-openssl.
> ...
>> Proposed patch restore previous behavior.
> I think that might break some systems that configure --without-openssl,
> so it probably better to move the test out of the if-else entirely.
I take this into account. This is reason to point to code where is used 
- only lines
# if defined(WITH_OPENSSL) && !defined(HAVE_CRYPT) && 
defined(HAVE_DES_CRYPT)
#  include <openssl/des.h>
#  define crypt DES_crypt
# endif

Build without openssl should not be impacted. On those system SSH cannot 
be build without libcrypto.


Regards,
Roumen Petrov


-- 
Get SSH with X.509 certificate support
http://roumenpetrov.info/openssh/


From djm at mindrot.org  Wed Mar  4 04:26:40 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 04:26:40 +1100 (AEDT)
Subject: openssh-SNAP-20150304 issues
In-Reply-To: <20150303152556.GA10317@doctor.nl2k.ab.ca>
References: <20150303152556.GA10317@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.11.1503040426060.6373@natsu.mindrot.org>



On Tue, 3 Mar 2015, The Doctor wrote:

> regress/unittests/test_helper/test_helper.c: In function `test_data_file':
> regress/unittests/test_helper/test_helper.c:177: warning: implicit declaration of function `strlcpy'
> regress/unittests/test_helper/test_helper.c: At top level:
> regress/unittests/test_helper/test_helper.c:196: parse error before "__unused"
> *** Error code 1

Could you try this?

diff --git a/defines.h b/defines.h
index fa0ccba..cf65901 100644
--- a/defines.h
+++ b/defines.h
@@ -850,4 +850,8 @@ struct winsize {
 # endif /* gcc version */
 #endif /* __predict_true */
 
+#ifndef __unused
+# define __unused
+#endif
+
 #endif /* _DEFINES_H */

From djm at mindrot.org  Wed Mar  4 04:54:40 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 04:54:40 +1100 (AEDT)
Subject: hostkey-rotate, grep and two line search pattern
In-Reply-To: <54F5EC56.3070807@roumenpetrov.info>
References: <54F5EC56.3070807@roumenpetrov.info>
Message-ID: <alpine.BSO.2.11.1503040433070.6373@natsu.mindrot.org>

On Tue, 3 Mar 2015, Roumen Petrov wrote:

> Hello,
> 
> Regression test hostkey-rotate .
> 
> After 'learn new primary' known_hosts contain both rsa keys - old and new one.
> Function check_key_present use awk to get search pattern and script return two
> lines.
> In such case Solaris grep command return error 41.
> Simple test command:
> $ grep '1
> > 2' /tmp/a
> grep: RE error 41: No remembered search string.
> 
> It is reported in [1] with patch to change grep to fgrep.
> As fgrep use "pattern as a list of fixed strings, separated by newlines" fgrep
> could be used to resolve issue.
> 
> 
> I would like to propose another correction - change logic of check_key_present
> to search known_hosts for public key.
> Attached file implement new search. It use 'fgrep ... > /dev/null'. Also 'grep
> -q ..' works well.

applied - thanks.

-d

From djm at mindrot.org  Wed Mar  4 05:02:35 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 05:02:35 +1100 (AEDT)
Subject: configure and have crypt or DES_crypt
In-Reply-To: <54F5EE3B.1050706@roumenpetrov.info>
References: <54F5A8F2.2000100@roumenpetrov.info>
 <alpine.BSO.2.11.1503040413160.6373@natsu.mindrot.org>
 <54F5EE3B.1050706@roumenpetrov.info>
Message-ID: <alpine.BSO.2.11.1503040454560.6373@natsu.mindrot.org>

On Tue, 3 Mar 2015, Roumen Petrov wrote:

> Damien Miller wrote:
>
> > I think that might break some systems that configure --without-openssl,
> > so it probably better to move the test out of the if-else entirely.
> I take this into account. This is reason to point to code where is used - only
> lines
> # if defined(WITH_OPENSSL) && !defined(HAVE_CRYPT) && defined(HAVE_DES_CRYPT)
> #  include <openssl/des.h>
> #  define crypt DES_crypt
> # endif
> 
> Build without openssl should not be impacted. On those system SSH cannot be
> build without libcrypto.

ok, I've committed this because it might be surprising that HAVE_CRYPT
is not defined on platforms that do have it.

diff --git a/configure.ac b/configure.ac
index 2ef9db6..b4d6598 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2572,6 +2572,7 @@ if test "x$openssl" = "xyes" ; then
 	if test "x$check_for_libcrypt_later" = "x1"; then
 		AC_CHECK_LIB([crypt], [crypt], [LIBS="$LIBS -lcrypt"])
 	fi
+	AC_CHECK_FUNCS([crypt DES_crypt])
 
 	# Search for SHA256 support in libc and/or OpenSSL
 	AC_CHECK_FUNCS([SHA256_Update EVP_sha256], ,
@@ -2710,7 +2711,7 @@ if test "x$openssl" = "xyes" ; then
 	AC_SUBST([COMMENT_OUT_ECC])
 else
 	AC_CHECK_LIB([crypt], [crypt], [LIBS="$LIBS -lcrypt"])
-	AC_CHECK_FUNCS([crypt DES_crypt])
+	AC_CHECK_FUNCS([crypt])
 fi
 
 AC_CHECK_FUNCS([ \

From gibsonmic at gmail.com  Wed Mar  4 05:06:47 2015
From: gibsonmic at gmail.com (John Dow)
Date: Tue, 3 Mar 2015 23:06:47 +0500
Subject: Building for CygWin without OpenSSL fails
Message-ID: <CAEKRuG4edEFf68A-OoTv8GMaWaKWAhj8H1FUCFyzYVZ0pqoA6g@mail.gmail.com>

Ok, I think I've figured that out. I used 6.7 stable and it was wrong.
Now I took 6.8 from master and configure --without-openssl went fine.
But now when make I see
...
openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt':
/cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:
undefined reference to `crypt'
/cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:(.text+0x5):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`crypt'


I tried to do

./configure --without-openssl --with-ldflags=-lcrypt

but configure fails with

checking compiler and flags for sanity... no
configure: error: *** compiler cannot create working executables,
check config.log ***

Here is my config.log
https://www.dropbox.com/s/65jqwybfh4m4msh/config.log?dl=0

I think have libcrypto and not sure what to do next

ls  -ld /lib/libcry*
-rw-r--r-- 1  9 01:05 /lib/libcrypto.a
-rwxr-xr-x  9 01:05 /lib/libcrypto.dll.a

2015-03-03 18:57 GMT+05:00 Corinna Vinschen <vinschen at redhat.com>:
> On Mar  3 18:43, John Dow wrote:
>> Already tried that. It says
>>
>> configure: WARNING: unrecognized options: --without-openssl
>>
>> 2015-03-03 17:56 GMT+05:00 Alex Bligh <alex at alex.org.uk>:
>> > John,
>> >
>> > On 3 Mar 2015, at 07:35, John Dow <gibsonmic at gmail.com> wrote:
>> >
>> >> ./configure > configure.log
>> >> https://www.dropbox.com/s/qgosxm73wdt7jhx/configure.log?dl=0
>> >>
>> >> make OPENSSL=no > make.log
>> >> https://www.dropbox.com/s/o7d5d3lu3jrfhxd/make.log?dl=0
>> >
>> > I know nothing about CygWin building, but you might want to try
>> >
>> > ./configure --without-openssl
>> > make
>> >
>> >
>> > --
>> > Alex Bligh
>
> Uhm, guys?  It's Cygwin, not CygWin.
>
>
> Just saying...
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
>
> _______________________________________________
> 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  Wed Mar  4 05:23:32 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 05:23:32 +1100 (AEDT)
Subject: Building for CygWin without OpenSSL fails
In-Reply-To: <CAEKRuG4edEFf68A-OoTv8GMaWaKWAhj8H1FUCFyzYVZ0pqoA6g@mail.gmail.com>
References: <CAEKRuG4edEFf68A-OoTv8GMaWaKWAhj8H1FUCFyzYVZ0pqoA6g@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503040521080.6373@natsu.mindrot.org>

On Tue, 3 Mar 2015, John Dow wrote:

> Ok, I think I've figured that out. I used 6.7 stable and it was wrong.
> Now I took 6.8 from master and configure --without-openssl went fine.
> But now when make I see
> ...
> openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt':
> /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:
> undefined reference to `crypt'
> /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:(.text+0x5):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `crypt'
> 
> 
> I tried to do
> 
> ./configure --without-openssl --with-ldflags=-lcrypt

Try "--with-libs=-lcrypt"

we do try to detect libcrypt already, so if this works then something
else has gone wrong. Do you have the cygwin-crypt package installed?

-d

From openssh at roumenpetrov.info  Wed Mar  4 06:23:19 2015
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Tue, 03 Mar 2015 21:23:19 +0200
Subject: openssh-SNAP-20150304 issues
In-Reply-To: <alpine.BSO.2.11.1503040426060.6373@natsu.mindrot.org>
References: <20150303152556.GA10317@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1503040426060.6373@natsu.mindrot.org>
Message-ID: <54F60A27.9070903@roumenpetrov.info>

Damien Miller wrote:
>
> On Tue, 3 Mar 2015, The Doctor wrote:
>
>> regress/unittests/test_helper/test_helper.c: In function `test_data_file':
>> regress/unittests/test_helper/test_helper.c:177: warning: implicit declaration of function `strlcpy'
>> regress/unittests/test_helper/test_helper.c: At top level:
>> regress/unittests/test_helper/test_helper.c:196: parse error before "__unused"
>> *** Error code 1
> Could you try this?
>
> diff --git a/defines.h b/defines.h
> index fa0ccba..cf65901 100644
> --- a/defines.h
> +++ b/defines.h
> @@ -850,4 +850,8 @@ struct winsize {
>   # endif /* gcc version */
>   #endif /* __predict_true */
>   
> +#ifndef __unused
> +# define __unused
> +#endif
> +
>   #endif /* _DEFINES_H */
After above patch linux build fail:
.................
make[1]: Entering directory `..../openbsd-compat'
gcc -O2 ..../arc4random.c
In file included from ..../arc4random.c:28:
/usr/include/netdb.h:589:15: error: expected identifier or ?(? 
before ?[? token
    int __unused[5];
..............

Regards,
Roumen

-- 
Get SSH with X.509 certificate support
http://roumenpetrov.info/openssh/


From djm at mindrot.org  Wed Mar  4 06:32:43 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 06:32:43 +1100 (AEDT)
Subject: openssh-SNAP-20150304 issues
In-Reply-To: <54F60A27.9070903@roumenpetrov.info>
References: <20150303152556.GA10317@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1503040426060.6373@natsu.mindrot.org>
 <54F60A27.9070903@roumenpetrov.info>
Message-ID: <alpine.BSO.2.11.1503040632260.6373@natsu.mindrot.org>

On Tue, 3 Mar 2015, Roumen Petrov wrote:

> After above patch linux build fail:
> .................
> make[1]: Entering directory `..../openbsd-compat'
> gcc -O2 ..../arc4random.c
> In file included from ..../arc4random.c:28:
> /usr/include/netdb.h:589:15: error: expected identifier or ?(? before ?[?
> token
>    int __unused[5];

bah, reverted

From vinschen at redhat.com  Wed Mar  4 06:50:28 2015
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 3 Mar 2015 20:50:28 +0100
Subject: Building for CygWin without OpenSSL fails
In-Reply-To: <alpine.BSO.2.11.1503040521080.6373@natsu.mindrot.org>
References: <CAEKRuG4edEFf68A-OoTv8GMaWaKWAhj8H1FUCFyzYVZ0pqoA6g@mail.gmail.com>
 <alpine.BSO.2.11.1503040521080.6373@natsu.mindrot.org>
Message-ID: <20150303195028.GU3213@calimero.vinschen.de>

On Mar  4 05:23, Damien Miller wrote:
> On Tue, 3 Mar 2015, John Dow wrote:
> 
> > Ok, I think I've figured that out. I used 6.7 stable and it was wrong.
> > Now I took 6.8 from master and configure --without-openssl went fine.
> > But now when make I see
> > ...
> > openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt':
> > /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:
> > undefined reference to `crypt'
> > /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:(.text+0x5):
> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> > `crypt'
> > 
> > 
> > I tried to do
> > 
> > ./configure --without-openssl --with-ldflags=-lcrypt
> 
> Try "--with-libs=-lcrypt"
> 
> we do try to detect libcrypt already, so if this works then something
> else has gone wrong. Do you have the cygwin-crypt package installed?

If that's on x86_64 Cygwin, the libcrypt-devel package is required
for building against libcrypt.  On 32 bit the package is still not
split, so the crypt package alone is sufficent.


HTH,
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: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150303/68863c4e/attachment-0001.bin>

From djm at mindrot.org  Wed Mar  4 08:36:52 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 4 Mar 2015 08:36:52 +1100 (AEDT)
Subject: openssh-SNAP-20150304 issues
In-Reply-To: <alpine.BSO.2.11.1503040632260.6373@natsu.mindrot.org>
References: <20150303152556.GA10317@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1503040426060.6373@natsu.mindrot.org>
 <54F60A27.9070903@roumenpetrov.info>
 <alpine.BSO.2.11.1503040632260.6373@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1503040836150.6373@natsu.mindrot.org>

On Wed, 4 Mar 2015, Damien Miller wrote:

> > gcc -O2 ..../arc4random.c
> > In file included from ..../arc4random.c:28:
> > /usr/include/netdb.h:589:15: error: expected identifier or ?(? before ?[?
> > token
> >    int __unused[5];
> 
> bah, reverted

I committed a less intrusive fix:


commit 3f7f5e6c5d2aa3f6710289c1a30119e534e56c5c
Author: djm at openbsd.org <djm at openbsd.org>
Date:   Tue Mar 3 20:42:49 2015 +0000

    upstream commit
    
    expand __unused to full __attribute__ for better portability

diff --git a/regress/unittests/test_helper/fuzz.c b/regress/unittests/test_helper/fuzz.c
index 06fb247..99f1d03 100644
--- a/regress/unittests/test_helper/fuzz.c
+++ b/regress/unittests/test_helper/fuzz.c
@@ -1,4 +1,4 @@
-/*	$OpenBSD: fuzz.c,v 1.7 2015/01/18 19:52:44 djm Exp $	*/
+/*	$OpenBSD: fuzz.c,v 1.8 2015/03/03 20:42:49 djm Exp $	*/
 /*
  * Copyright (c) 2011 Damien Miller <djm at mindrot.org>
  *
@@ -200,7 +200,7 @@ fuzz_dump(struct fuzz *fuzz)
 static struct fuzz *last_fuzz;
 
 static void
-siginfo(int unused __unused)
+siginfo(int unused __attribute__((__unused__)))
 {
 	char buf[256];
 
diff --git a/regress/unittests/test_helper/test_helper.c b/regress/unittests/test_helper/test_helper.c
index 034af93..26ca26b 100644
--- a/regress/unittests/test_helper/test_helper.c
+++ b/regress/unittests/test_helper/test_helper.c
@@ -1,4 +1,4 @@
-/*	$OpenBSD: test_helper.c,v 1.5 2015/02/16 22:20:50 djm Exp $	*/
+/*	$OpenBSD: test_helper.c,v 1.6 2015/03/03 20:42:49 djm Exp $	*/
 /*
  * Copyright (c) 2011 Damien Miller <djm at mindrot.org>
  *
@@ -193,7 +193,7 @@ test_info(char *s, size_t len)
 
 #ifdef SIGINFO
 static void
-siginfo(int unused __unused)
+siginfo(int unused __attribute__((__unused__)))
 {
 	char buf[256];
 

From gibsonmic at gmail.com  Wed Mar  4 14:16:48 2015
From: gibsonmic at gmail.com (John Dow)
Date: Wed, 4 Mar 2015 08:16:48 +0500
Subject: Building for CygWin without OpenSSL fails
In-Reply-To: <20150303195028.GU3213@calimero.vinschen.de>
References: <CAEKRuG4edEFf68A-OoTv8GMaWaKWAhj8H1FUCFyzYVZ0pqoA6g@mail.gmail.com>
 <alpine.BSO.2.11.1503040521080.6373@natsu.mindrot.org>
 <20150303195028.GU3213@calimero.vinschen.de>
Message-ID: <CAEKRuG7FfU4NdeUn2NmYLWKdwCU0nr968tb1Pz3SkKMPEz5LtQ@mail.gmail.com>

Thanks a lot, that worked

2015-03-04 0:50 GMT+05:00 Corinna Vinschen <vinschen at redhat.com>:
> On Mar  4 05:23, Damien Miller wrote:
>> On Tue, 3 Mar 2015, John Dow wrote:
>>
>> > Ok, I think I've figured that out. I used 6.7 stable and it was wrong.
>> > Now I took 6.8 from master and configure --without-openssl went fine.
>> > But now when make I see
>> > ...
>> > openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt':
>> > /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:
>> > undefined reference to `crypt'
>> > /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:(.text+0x5):
>> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>> > `crypt'
>> >
>> >
>> > I tried to do
>> >
>> > ./configure --without-openssl --with-ldflags=-lcrypt
>>
>> Try "--with-libs=-lcrypt"
>>
>> we do try to detect libcrypt already, so if this works then something
>> else has gone wrong. Do you have the cygwin-crypt package installed?
>
> If that's on x86_64 Cygwin, the libcrypt-devel package is required
> for building against libcrypt.  On 32 bit the package is still not
> split, so the crypt package alone is sufficent.
>
>
> HTH,
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From mikep at noc.utoronto.ca  Thu Mar  5 07:11:50 2015
From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca)
Date: Wed, 4 Mar 2015 15:11:50 -0500 (EST)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
Message-ID: <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>

Re-testing 'openssh-SNAP-20150305' on Solaris 10, with 'gcc':

Configure, 'make' complete; 'make tests' fails at:

run test sftp-perm.sh ...
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
make[1]: Leaving directory `/opt/local/src/security/openssh/regress'
make: *** [tests] Error 2


'regress.log' shows:

trace: sftp permissions: explicit statvfs


'failed-regress.log' shows:

trace: sftp permissions: read-only setstat
FAIL: postcondition check failed: setstat readonly

trace: sftp permissions: explicit setstat
FAIL: postcondition check failed: setstat blacklisted

trace: sftp permissions: explicit setstat
FAIL: postcondition check failed: setstat blacklisted
FAIL: postcondition check failed: setstat not in whitelist


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 djm at mindrot.org  Fri Mar  6 12:30:20 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 6 Mar 2015 12:30:20 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
Message-ID: <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>

On Wed, 4 Mar 2015, mikep at noc.utoronto.ca wrote:

> Re-testing 'openssh-SNAP-20150305' on Solaris 10, with 'gcc':
> 
> Configure, 'make' complete; 'make tests' fails at:
> 
> postcondition check failed: setstat readonly

I couldn't reporoduce this on an illumos zone that I had access to,
will try installing solaris10 next.

-d

From hecht at hlrs.de  Fri Mar  6 21:17:00 2015
From: hecht at hlrs.de (Martin Hecht)
Date: Fri, 06 Mar 2015 11:17:00 +0100
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
Message-ID: <54F97E9C.6020101@hlrs.de>

on Ubuntu 14.04 with openssh-SNAP-20150306.tar.gz with gcc, libz-dev,
and libssl-dev

configure; make; make tests

fails at:

test_hostkeys:
regress/unittests/hostkeys/test_iterate.c:124 test #1 "hostkeys_iterate
all with key parse" - entry 5/61, file line 5
ASSERT_PTR_EQ(l->key, NULL) failed:
      l->key = 0x2b14c2d7af80
        NULL = (nil)
Aborted
make[1]: *** [unit] Error 134
make[1]: Leaving directory `/home/hpcmhech/tmp/openssh/regress'
make: *** [tests] Error 2

I have also tried to run make install in-between, and created new
host-keys, but tests didn't pass at the same point.


OpenSSH has been configured with the following options:
                     User binaries: /usr/local/bin
                   System binaries: /usr/local/sbin
               Configuration files: /usr/local/etc
                   Askpass program: /usr/local/libexec/ssh-askpass
                      Manual pages: /usr/local/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
                    Manpage format: doc
                       PAM support: no
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: no
                 Smartcard support:
                     S/KEY support: no
              MD5 password support: no
                   libedit support: no
  Solaris process contract support: no
           Solaris project support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY
             Privsep sandbox style: seccomp_filter

              Host: x86_64-unknown-linux-gnu
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
-Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing
-D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all -fPIE
Preprocessor flags:
      Linker flags:  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-fstack-protector-all -pie
         Libraries: -lcrypto -ldl -lutil -lz -lnsl  -lcrypt -lresolv


On 02/19/2015 11:21 PM, Damien Miller wrote:
> Hi,
>
> OpenSSH 6.8 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
>
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
>
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
>
> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs or
> via Git at https://anongit.mindrot.org/openssh.git/
>
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
>
> $ ./configure && make tests
>
> Live testing on suitable non-production systems is also
> appreciated. Please send reports of success or failure to
> openssh-unix-dev at mindrot.org.
>
> Below is a summary of changes. More detail may be found in the ChangeLog
> in the portable OpenSSH tarballs.
>
> Thanks to the many people who contributed to this release.
>
> Changes since OpenSSH 6.7
> =========================
>
> This is a major release, containing a number of new features as
> well as a large internal re-factoring.
>
> Potentially-incompatible changes
> --------------------------------
>
>  * sshd(8): UseDNS now defaults to 'no'. Configurations that match
>    against the client host name (via sshd_config or authorized_keys)
>    may need to re-enable it or convert to matching against addresses.
>
> New Features
> ------------
>
>  * Much of OpenSSH's internal code has been re-factored to be more
>    library-like. These changes are mostly not user-visible, but
>    have greatly improved OpenSSH's testability and internal layout.
>
>  * Add FingerprintHash option to ssh(1) and sshd(8), and equivalent
>    command-line flags to the other tools to control algorithm used
>    for key fingerprints. The default changes from MD5 to SHA256 and
>    format from hex to base64.
>
>    Fingerprints now have the hash algorithm prepended. An example of
>    the new format: SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE
>    Please note that visual host keys will also be different.
>
>  * ssh(1), sshd(8): Host key rotation support. Add a protocol
>    extension for a server to inform a client of all its available
>    host keys after authentication has completed. The client may
>    record the keys in known_hosts, allowing it to upgrade to better
>    host key algorithms and a server to gracefully rotate its keys.
>
>    The client side of this is controlled by a UpdateHostkeys config
>    option (default on).
>
>  * ssh(1): Add a ssh_config HostbasedKeyType option to control which
>    host public key types are tried during host-based authentication.
>
>  * ssh(1), sshd(8): fix connection-killing host key mismatch errors
>    when sshd offers multiple ECDSA keys of different lengths.
>
>  * ssh(1): when host name canonicalisation is enabled, try to
>    parse host names as addresses before looking them up for
>    canonicalisation. fixes bz#2074 and avoiding needless DNS
>    lookups in some cases.
>
>  * ssh-keygen(1), sshd(8): Key Revocation Lists (KRLs) no longer
>    require OpenSSH to be compiled with OpenSSL support.
>
>  * ssh(1), ssh-keysign(8): Make ed25519 keys work for host based
>    authentication.
>
>  * sshd(8): SSH protocol v.1 workaround for the Meyer, et al,
>    Bleichenbacher Side Channel Attack. Fake up a bignum key before
>    RSA decryption.
>
>  * sshd(8): Remember which public keys have been used for
>    authentication and refuse to accept previously-used keys.
>    This allows AuthenticationMethods=publickey,publickey to require
>    that users authenticate using two _different_ public keys.
>
>  * sshd(8): add sshd_config HostbasedAcceptedKeyTypes and
>    PubkeyAcceptedKeyTypes options to allow sshd to control what
>    public key types will be accepted. Currently defaults to all.
>
>  * sshd(8): Don't count partial authentication success as a failure
>    against MaxAuthTries.
>
>  * ssh(1): Add RevokedHostKeys option for the client to allow
>    text-file or KRL-based revocation of host keys.
>
>  * ssh-keygen(1), sshd(8): Permit KRLs that revoke certificates by
>    serial number or key ID without scoping to a particular CA.
>
>  * ssh(1): Add a "Match canonical" criteria that allows ssh_config
>    Match blocks to trigger only in the second config pass.
>
>  * ssh(1): Add a -G option to ssh that causes it to parse its
>    configuration and dump the result to stdout, similar to "sshd -T".
>
>  * ssh(1): Allow Match criteria to be negated. E.g. "Match !host".
>
>  * The regression test suite has been extended to cover more OpenSSH
>    features. The unit tests have been expanded and now cover key
>    exchange.
>
> Bugfixes
> --------
>
>  * ssh-keyscan(1): ssh-keyscan has been made much more robust again
>    servers that hang or violate the SSH protocol.
>
>  * ssh(1), ssh-keygen(1): Fix regression bz#2306: Key path names were
>    being lost as comment fields.
>
>  * ssh(1): Allow ssh_config Port options set in the second config
>    parse phase to be applied (they were being ignored). bz#2286
>
>  * ssh(1): Tweak config re-parsing with host canonicalisation - make
>    the second pass through the config files always run when host name
>    canonicalisation is enabled (and not whenever the host name
>    changes) bz#2267
>
>  * ssh(1): Fix passing of wildcard forward bind addresses when
>    connection multiplexing is in use; bz#2324;
>
>  * ssh-keygen(1): Fix broken private key conversion from non-OpenSSH
>    formats; bz#2345.
>
>  * ssh-keygen(1): Fix KRL generation bug when multiple CAs are in
>    use.
>
>  * Various fixed to manual pages: bz#2288, bz#2316, bz#2273
>
> Portable OpenSSH
> ----------------
>
>  * Support --without-openssl at configure time
>
>    Disables and removes dependency on OpenSSL. Many features,
>    including SSH protocol 1 are not supported and the set of crypto
>    options is greatly restricted. This will only work on system with
>    native arc4random or /dev/urandom.
>
>    Considered highly experimental for now.
>
>  * Support --without-ssh1 option at configure time
>
>    Allows disabling support for SSH protocol 1.
>
>    Still experimental - not all regression and unit tests have been
>    been adapted for the absence of SSH protocol 1.
>
>  * sshd(8): Fix compilation on systems with IPv6 support in utmpx; bz#2296
>
>  * Allow custom service name for sshd on Cygwin. Permits the use of
>    multiple sshd running with different service names.
>
> 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. Martin Hecht
High Performance Computing Center Stuttgart (HLRS)
Office 0.051, HPCN Production, IT-Security
University of Stuttgart
Nobelstra?e 19, 70569 Stuttgart, Germany
Tel: +49(0)711/685-65799  Fax: -55799
Mail: hecht at hlrs.de
Web: http://www.hlrs.de/people/hecht/
PGP Key Fingerprint: 41BB 33E9 7170 3864 D5B3 44AD 5490 010B 96C2 6E4A



From hecht at hlrs.de  Fri Mar  6 21:31:41 2015
From: hecht at hlrs.de (Martin Hecht)
Date: Fri, 06 Mar 2015 11:31:41 +0100
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <54F97E9C.6020101@hlrs.de>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <54F97E9C.6020101@hlrs.de>
Message-ID: <54F9820D.2080301@hlrs.de>

On 03/06/2015 11:17 AM, Martin Hecht wrote:
> on Ubuntu 14.04 with openssh-SNAP-20150306.tar.gz with gcc, libz-dev,
> and libssl-dev
another thing:

if I uninstall libssl-dev and run configure --without-openssl it is
happy, but make fails afterwards with

(cd openbsd-compat && make)
make[1]: Entering directory `/home/hpcmhech/tmp/openssh/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
-Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign
-Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
-fno-builtin-memset -fstack-protector-all -fPIE  -I. -I.. -I. -I./.. 
-DHAVE_CONFIG_H -c arc4random.c
In file included from ../entropy.h:30:0,
                 from ../includes.h:180,
                 from arc4random.c:27:
../buffer.h:50:29: fatal error: openssl/objects.h: No such file or directory
 #include <openssl/objects.h>
                             ^
compilation terminated.
make[1]: *** [arc4random.o] Error 1
make[1]: Leaving directory `/home/hpcmhech/tmp/openssh/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2


From hecht at hlrs.de  Sat Mar  7 02:43:14 2015
From: hecht at hlrs.de (Martin Hecht)
Date: Fri, 06 Mar 2015 16:43:14 +0100
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <54F97E9C.6020101@hlrs.de>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <54F97E9C.6020101@hlrs.de>
Message-ID: <54F9CB12.30804@hlrs.de>

On 03/06/2015 11:17 AM, Martin Hecht wrote:
> on Ubuntu 14.04 with openssh-SNAP-20150306.tar.gz with gcc, libz-dev,
> and libssl-dev
>
> configure; make; make tests
>
> fails at:
>
> test_hostkeys:
> regress/unittests/hostkeys/test_iterate.c:124 test #1 "hostkeys_iterate
> all with key parse" - entry 5/61, file line 5
> ASSERT_PTR_EQ(l->key, NULL) failed:
>       l->key = 0x2b14c2d7af80
>         NULL = (nil)
> Aborted
> make[1]: *** [unit] Error 134
> make[1]: Leaving directory `/home/hpcmhech/tmp/openssh/regress'
> make: *** [tests] Error 2
I could reproduce this on a redhat-clone, as well,

and: openssh-SNAP-20150305.tar.gz ran through smoothly - so this
regression has been
introduced very recently (Mar 5):

hpcmhech at localhost(512):~/tmp/openssh-20150306/openssh> ls -la
regress/unittests/hostkeys/test_iterate.c
-rw-r--r-- 1 hpcmhech users 25308 Mar  5 00:39
regress/unittests/hostkeys/test_iterate.c

I'm running my system at CET (+0100)





From djm at mindrot.org  Sat Mar  7 04:34:20 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 7 Mar 2015 04:34:20 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <54F97E9C.6020101@hlrs.de>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <54F97E9C.6020101@hlrs.de>
Message-ID: <alpine.BSO.2.11.1503070433570.12359@natsu.mindrot.org>

On Fri, 6 Mar 2015, Martin Hecht wrote:

> on Ubuntu 14.04 with openssh-SNAP-20150306.tar.gz with gcc, libz-dev,
> and libssl-dev
> 
> configure; make; make tests
> 
> fails at:
> 
> test_hostkeys:
> regress/unittests/hostkeys/test_iterate.c:124 test #1 "hostkeys_iterate
> all with key parse" - entry 5/61, file line 5
> ASSERT_PTR_EQ(l->key, NULL) failed:
>       l->key = 0x2b14c2d7af80
>         NULL = (nil)

Already fixed in HEAD:

diff --git sshkey.c sshkey.c
index 2c67809..680c707 100644
--- sshkey.c
+++ sshkey.c
@@ -2464,6 +2464,7 @@ sshkey_certify(struct sshkey *k, struct sshkey *ca)
 		break;
 	default:
 		ret = SSH_ERR_INVALID_ARGUMENT;
+		goto out;
 	}
 
 	/* -v01 certs have a serial number next */

From djm at mindrot.org  Sat Mar  7 04:39:47 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 7 Mar 2015 04:39:47 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <54F9820D.2080301@hlrs.de>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <54F97E9C.6020101@hlrs.de> <54F9820D.2080301@hlrs.de>
Message-ID: <alpine.BSO.2.11.1503070438480.12359@natsu.mindrot.org>

On Fri, 6 Mar 2015, Martin Hecht wrote:

> On 03/06/2015 11:17 AM, Martin Hecht wrote:
> > on Ubuntu 14.04 with openssh-SNAP-20150306.tar.gz with gcc, libz-dev,
> > and libssl-dev
> another thing:
> 
> if I uninstall libssl-dev and run configure --without-openssl it is
> happy, but make fails afterwards with

Yes, we still require the OpenSSL headers even when compiling
--without-openssl. Removing the compile-time dependency will
will require quite a few more ifdefs, perhaps too many to be
palatable.

-d

From djm at mindrot.org  Sat Mar  7 04:40:23 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 7 Mar 2015 04:40:23 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <alpine.BSO.2.11.1503070433570.12359@natsu.mindrot.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <54F97E9C.6020101@hlrs.de>
 <alpine.BSO.2.11.1503070433570.12359@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1503070439550.12359@natsu.mindrot.org>



On Sat, 7 Mar 2015, Damien Miller wrote:

> On Fri, 6 Mar 2015, Martin Hecht wrote:
> 
> > on Ubuntu 14.04 with openssh-SNAP-20150306.tar.gz with gcc, libz-dev,
> > and libssl-dev
> > 
> > configure; make; make tests
> > 
> > fails at:
> > 
> > test_hostkeys:
> > regress/unittests/hostkeys/test_iterate.c:124 test #1 "hostkeys_iterate
> > all with key parse" - entry 5/61, file line 5
> > ASSERT_PTR_EQ(l->key, NULL) failed:
> >       l->key = 0x2b14c2d7af80
> >         NULL = (nil)
> 
> Already fixed in HEAD:

oops, wrong diff - this is the fix for the unit test failure:

commit b44ee0c998fb4c5f3c3281f2398af5ce42840b6f
Author: Damien Miller <djm at mindrot.org>
Date:   Thu Mar 5 18:39:20 2015 -0800

    unbreak hostkeys test for w/ SSH1 case

diff --git regress/unittests/hostkeys/test_iterate.c regress/unittests/hostkeys/test_iterate.c
index fc095ea..5ea576c 100644
--- regress/unittests/hostkeys/test_iterate.c
+++ regress/unittests/hostkeys/test_iterate.c
@@ -141,8 +141,10 @@ prepare_expected(struct expected *expected, size_t n)
 	for (i = 0; i < n; i++) {
 		if (expected[i].key_file == NULL)
 			continue;
+#ifndef WITH_SSH1
 		if (expected[i].l.keytype == KEY_RSA1)
 			continue;
+#endif
 		ASSERT_INT_EQ(sshkey_load_public(
 		    test_data_file(expected[i].key_file), &expected[i].l.key,
 		    NULL), 0);

From djm at mindrot.org  Tue Mar 10 14:50:20 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 10 Mar 2015 14:50:20 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>

On Fri, 6 Mar 2015, Damien Miller wrote:

> On Wed, 4 Mar 2015, mikep at noc.utoronto.ca wrote:
> 
> > Re-testing 'openssh-SNAP-20150305' on Solaris 10, with 'gcc':
> > 
> > Configure, 'make' complete; 'make tests' fails at:
> > 
> > postcondition check failed: setstat readonly
> 
> I couldn't reporoduce this on an illumos zone that I had access to,
> will try installing solaris10 next.

I've been unable to get Solaris 10 working in a VM. Could you please
apply the below patch and run:

make tests LTESTS=sftp-perm SKIP_UNIT=1

and report the last 20 or so lines of output? (I'm mostly interested in those
prefixed with 'XXX')

diff --git a/regress/sftp-perm.sh b/regress/sftp-perm.sh
index 304ca0a..9a3740e 100644
--- a/regress/sftp-perm.sh
+++ b/regress/sftp-perm.sh
@@ -41,13 +41,17 @@ ro_test() {
 	verbose "$tid: read-only $_desc"
 	# Plain (no options, mostly to test that _cmd is good)
 	prepare_files "$_prep"
+	printf "XXX PRE RW: " ; ls -l $COPY
 	prepare_server
 	run_client "$_cmd" || fail "plain $_desc failed"
+	printf "XXX POST RW: " ; ls -l $COPY
 	postcondition "$_desc no-readonly" "$_expect_success_post"
 	# Read-only enabled
 	prepare_files "$_prep"
+	printf "XXX PRE RO: " ; ls -l $COPY
 	prepare_server -R
 	run_client "$_cmd" && fail "read-only $_desc succeeded"
+	printf "XXX POST RO: " ; ls -l $COPY
 	postcondition "$_desc readonly" "$_expect_fail_post"
 }
 
@@ -80,20 +84,22 @@ perm_test() {
 	run_client "$_cmd" && fail "no whitelist $_op succeeded"
 	postcondition "$_op not in whitelist" "$_expect_fail_post"
 }
-
+if false ; then
 ro_test \
 	"upload" \
 	"put $DATA $COPY" \
 	"" \
 	"cmp $DATA $COPY" \
 	"test ! -f $COPY"
-
+fi
+echo YYY
 ro_test \
 	"setstat" \
 	"chmod 0700 $COPY" \
 	"touch $COPY; chmod 0400 $COPY" \
 	"test -x $COPY" \
 	"test ! -x $COPY"
+fatal XXX
 
 ro_test \
 	"rm" \

From mikep at noc.utoronto.ca  Thu Mar 12 08:52:05 2015
From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca)
Date: Wed, 11 Mar 2015 17:52:05 -0400 (EDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
 <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
Message-ID: <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>

On Tue, 10 Mar 2015, Damien Miller wrote:

> On Fri, 6 Mar 2015, Damien Miller wrote:
>
>> On Wed, 4 Mar 2015, mikep at noc.utoronto.ca wrote:
>>
>>> Re-testing 'openssh-SNAP-20150305' on Solaris 10, with 'gcc':
>>>
>>> Configure, 'make' complete; 'make tests' fails at:
>>>
>>> postcondition check failed: setstat readonly
>>
>> I couldn't reporoduce this on an illumos zone that I had access to,
>> will try installing solaris10 next.
>
> I've been unable to get Solaris 10 working in a VM. Could you please
> apply the below patch and run:
>
> make tests LTESTS=sftp-perm SKIP_UNIT=1
>
> and report the last 20 or so lines of output? (I'm mostly interested in those
> prefixed with 'XXX')

/opt/local/src/security/openssh/ssh-keygen -lf /opt/local/src/security/openssh/regress//t10.out > /dev/null
/opt/local/src/security/openssh/ssh-keygen -Bf /opt/local/src/security/openssh/regress//t10.out > /dev/null
/opt/local/src/security/openssh/ssh-keygen -E sha256 -lf /opt/local/src/security/openssh/regress/rsa_openssh.pub |\
         awk '{print $2}' | diff - /opt/local/src/security/openssh/regress/t11.ok
/opt/local/src/security/openssh/ssh-keygen -lf /opt/local/src/security/openssh/regress//t12.out.pub | grep -q test-comment-1234
run test sftp-perm.sh ...
YYY
sftp permissions: read-only setstat
XXX PRE RW: -r--------   1 root            0 Mar 11 17:48 /opt/local/src/security/openssh/regress/copy
XXX POST RW: -rwx------   1 root            0 Mar 11 17:48 /opt/local/src/security/openssh/regress/copy
XXX PRE RO: -r--------   1 root            0 Mar 11 17:48 /opt/local/src/security/openssh/regress/copy
XXX POST RO: -r--------   1 root            0 Mar 11 17:48 /opt/local/src/security/openssh/regress/copy
postcondition check failed: setstat readonly
FATAL: XXX
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/opt/local/src/security/openssh/regress'
make: *** [tests] Error 2

> diff --git a/regress/sftp-perm.sh b/regress/sftp-perm.sh
> index 304ca0a..9a3740e 100644
> --- a/regress/sftp-perm.sh
> +++ b/regress/sftp-perm.sh
> @@ -41,13 +41,17 @@ ro_test() {
> 	verbose "$tid: read-only $_desc"
> 	# Plain (no options, mostly to test that _cmd is good)
> 	prepare_files "$_prep"
> +	printf "XXX PRE RW: " ; ls -l $COPY
> 	prepare_server
> 	run_client "$_cmd" || fail "plain $_desc failed"
> +	printf "XXX POST RW: " ; ls -l $COPY
> 	postcondition "$_desc no-readonly" "$_expect_success_post"
> 	# Read-only enabled
> 	prepare_files "$_prep"
> +	printf "XXX PRE RO: " ; ls -l $COPY
> 	prepare_server -R
> 	run_client "$_cmd" && fail "read-only $_desc succeeded"
> +	printf "XXX POST RO: " ; ls -l $COPY
> 	postcondition "$_desc readonly" "$_expect_fail_post"
> }
>
> @@ -80,20 +84,22 @@ perm_test() {
> 	run_client "$_cmd" && fail "no whitelist $_op succeeded"
> 	postcondition "$_op not in whitelist" "$_expect_fail_post"
> }
> -
> +if false ; then
> ro_test \
> 	"upload" \
> 	"put $DATA $COPY" \
> 	"" \
> 	"cmp $DATA $COPY" \
> 	"test ! -f $COPY"
> -
> +fi
> +echo YYY
> ro_test \
> 	"setstat" \
> 	"chmod 0700 $COPY" \
> 	"touch $COPY; chmod 0400 $COPY" \
> 	"test -x $COPY" \
> 	"test ! -x $COPY"
> +fatal XXX
>
> ro_test \
> 	"rm" \


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 djm at mindrot.org  Thu Mar 12 09:17:28 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 12 Mar 2015 09:17:28 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
 <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
 <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>
Message-ID: <alpine.BSO.2.11.1503120853400.17334@natsu.mindrot.org>

On Wed, 11 Mar 2015, mikep at noc.utoronto.ca wrote:

> sftp permissions: read-only setstat
> XXX PRE RW: -r--------   1 root            0 Mar 11 17:48
> /opt/local/src/security/openssh/regress/copy
> XXX POST RW: -rwx------   1 root            0 Mar 11 17:48
> /opt/local/src/security/openssh/regress/copy
> XXX PRE RO: -r--------   1 root            0 Mar 11 17:48
> /opt/local/src/security/openssh/regress/copy
> XXX POST RO: -r--------   1 root            0 Mar 11 17:48

Thanks. It looks like sftp-server is behaving correctly but the test
logic isn't. Specifically, it seems 'test ! -x $COPY' is returning
false even though $COPY is not executable.

I've not seen Solaris' test behave like this before, so I'm not sure
what is going on here...

-d

From mikep at noc.utoronto.ca  Fri Mar 13 03:37:08 2015
From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca)
Date: Thu, 12 Mar 2015 12:37:08 -0400 (EDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <alpine.BSO.2.11.1503120853400.17334@natsu.mindrot.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
 <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
 <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503120853400.17334@natsu.mindrot.org>
Message-ID: <Pine.GSO.4.64.1503121151390.18849@kraken.noc.utoronto.ca>

On Thu, 12 Mar 2015, Damien Miller wrote:

> On Wed, 11 Mar 2015, mikep at noc.utoronto.ca wrote:
>
>> sftp permissions: read-only setstat
>> XXX PRE RW: -r--------   1 root            0 Mar 11 17:48
>> /opt/local/src/security/openssh/regress/copy
>> XXX POST RW: -rwx------   1 root            0 Mar 11 17:48
>> /opt/local/src/security/openssh/regress/copy
>> XXX PRE RO: -r--------   1 root            0 Mar 11 17:48
>> /opt/local/src/security/openssh/regress/copy
>> XXX POST RO: -r--------   1 root            0 Mar 11 17:48
>
> Thanks. It looks like sftp-server is behaving correctly but the test
> logic isn't. Specifically, it seems 'test ! -x $COPY' is returning
> false even though $COPY is not executable.
>
> I've not seen Solaris' test behave like this before, so I'm not sure
> what is going on here...

I had the same issue with OpenSSH 6.7, which was never resolved; we do 
have '/usr/ucb' on our paths, but I renamed '/usr/ucb/test' to 
'/usr/ucb/test.sav' many years ago as it messed up other builds/installs.

Any other tests/checks I can run?

> -d

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 mikep at noc.utoronto.ca  Fri Mar 13 07:34:18 2015
From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca)
Date: Thu, 12 Mar 2015 16:34:18 -0400 (EDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <5501E4BA.10604@taltos.org>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
 <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
 <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503120853400.17334@natsu.mindrot.org>
 <Pine.GSO.4.64.1503121151390.18849@kraken.noc.utoronto.ca>
 <5501E4BA.10604@taltos.org>
Message-ID: <Pine.GSO.4.64.1503121630140.18849@kraken.noc.utoronto.ca>

On Thu, 12 Mar 2015, Carson Gaspar wrote:

> On 3/12/15 9:37 AM, mikep at noc.utoronto.ca wrote:
>
>> I had the same issue with OpenSSH 6.7, which was never resolved; we do
>> have '/usr/ucb' on our paths, but I renamed '/usr/ucb/test' to
>> '/usr/ucb/test.sav' many years ago as it messed up other builds/installs.
>> 
>> Any other tests/checks I can run?
>
> Try with SHELL=TEST_SHELL=/bin/bash

Tried with:

make SHELL=/bin/sh TEST_SHELL=/bin/sh tests LTESTS=sftp-perm SKIP_UNIT=1
make SHELL=/bin/bash TEST_SHELL=/bin/bash tests LTESTS=sftp-perm 
SKIP_UNIT=1
make SHELL=/bin/ksh TEST_SHELL=/bin/ksh tests LTESTS=sftp-perm SKIP_UNIT=1

All fail at the same point, although the '/bin/sh' fails with:

run test sftp-perm.sh ...
/opt/local/src/security/openssh/regress/test-exec.sh: test: unknown 
operator -nt
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/opt/local/src/security/openssh/regress'
make: *** [tests] Error 2

instead of:

run test sftp-perm.sh ...
YYY
sftp permissions: read-only setstat
XXX PRE RW: -r--------   1 root            0 Mar 12 16:29 
/opt/local/src/security/openssh/regress/copy
XXX POST RW: -rwx------   1 root            0 Mar 12 16:29 
/opt/local/src/security/openssh/regress/copy
XXX PRE RO: -r--------   1 root            0 Mar 12 16:29 
/opt/local/src/security/openssh/regress/copy
XXX POST RO: -r--------   1 root            0 Mar 12 16:29 
/opt/local/src/security/openssh/regress/copy
postcondition check failed: setstat readonly
FATAL: XXX
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/opt/local/src/security/openssh/regress'
make: *** [tests] Error 2

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 djm at mindrot.org  Fri Mar 13 13:30:33 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 13 Mar 2015 13:30:33 +1100 (AEDT)
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <Pine.GSO.4.64.1503121630140.18849@kraken.noc.utoronto.ca>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
 <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
 <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503120853400.17334@natsu.mindrot.org>
 <Pine.GSO.4.64.1503121151390.18849@kraken.noc.utoronto.ca>
 <5501E4BA.10604@taltos.org>
 <Pine.GSO.4.64.1503121630140.18849@kraken.noc.utoronto.ca>
Message-ID: <alpine.BSO.2.11.1503131329150.30005@natsu.mindrot.org>

On Thu, 12 Mar 2015, mikep at noc.utoronto.ca wrote:

> On Thu, 12 Mar 2015, Carson Gaspar wrote:
> 
> > On 3/12/15 9:37 AM, mikep at noc.utoronto.ca wrote:
> > 
> > > I had the same issue with OpenSSH 6.7, which was never resolved; we do
> > > have '/usr/ucb' on our paths, but I renamed '/usr/ucb/test' to
> > > '/usr/ucb/test.sav' many years ago as it messed up other builds/installs.
> > > 
> > > Any other tests/checks I can run?
> > 
> > Try with SHELL=TEST_SHELL=/bin/bash
> 
> Tried with:
> 
> make SHELL=/bin/sh TEST_SHELL=/bin/sh tests LTESTS=sftp-perm SKIP_UNIT=1
> make SHELL=/bin/bash TEST_SHELL=/bin/bash tests LTESTS=sftp-perm SKIP_UNIT=1
> make SHELL=/bin/ksh TEST_SHELL=/bin/ksh tests LTESTS=sftp-perm SKIP_UNIT=1
> 
> All fail at the same point, although the '/bin/sh' fails with:

If you are running with they patch then they will definitely all fail
because the testing patch I sent you adds a "fatal XXX" to prevent
extraneous output from being shown.

You should revert it before testing.

-d

From doctor at doctor.nl2k.ab.ca  Sat Mar 14 03:48:34 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Fri, 13 Mar 2015 10:48:34 -0600
Subject: Call for testing: OpenSSH 6.8
In-Reply-To: <Pine.GSO.4.64.1503121151390.18849@kraken.noc.utoronto.ca>
References: <alpine.BSO.2.11.1502200909220.4850@natsu.mindrot.org>
 <Pine.GSO.4.64.1503041505180.5411@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503061229300.15432@natsu.mindrot.org>
 <alpine.BSO.2.11.1503101441310.28549@natsu.mindrot.org>
 <Pine.GSO.4.64.1503111750010.14052@kraken.noc.utoronto.ca>
 <alpine.BSO.2.11.1503120853400.17334@natsu.mindrot.org>
 <Pine.GSO.4.64.1503121151390.18849@kraken.noc.utoronto.ca>
Message-ID: <20150313164832.GA13604@doctor.nl2k.ab.ca>

More information headed your way:

Test:


Script started on Fri Mar 13 10:27:20 2015
doctor.nl2k.ab.ca//usr/source/openssh-SNAP-20150314$ make tests
[ -d `pwd`/regress ] || mkdir -p `pwd`/regress
[ -d `pwd`/regress/unittests ] || mkdir -p `pwd`/regress/unittests
[ -d `pwd`/regress/unittests/test_helper ] ||  mkdir -p `pwd`/regress/unittests/test_helper
[ -d `pwd`/regress/unittests/sshbuf ] ||  mkdir -p `pwd`/regress/unittests/sshbuf
[ -d `pwd`/regress/unittests/sshkey ] ||  mkdir -p `pwd`/regress/unittests/sshkey
[ -d `pwd`/regress/unittests/bitmap ] ||  mkdir -p `pwd`/regress/unittests/bitmap
[ -d `pwd`/regress/unittests/hostkeys ] ||  mkdir -p `pwd`/regress/unittests/hostkeys
[ -d `pwd`/regress/unittests/kex ] ||  mkdir -p `pwd`/regress/unittests/kex
[ -f `pwd`/regress/Makefile ] ||  ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile
(cd openbsd-compat && make)
/usr/bin/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/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat  -lcrypto -ldl -lutil -lz 
/usr/bin/gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o  audit.o audit-bsm.o audit-linux.o platform.o  sshpty.o sshlogin.o servconf.o serverloop.o  auth.o auth1.o auth2.o auth-options.o session.o  auth-chall.o auth2-chall.o groupaccess.o  auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o  auth2-none.o auth2-passwd.o auth2-pubkey.o  monitor_mm.o monitor.o monitor_wrap.o auth-krb5.o  auth2-gss.o gss-serv.o gss-serv-krb5.o  loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o  sftp-server.o sftp-common.o  roaming_common.o roaming_serv.o  sandbox-null.o sandbox-rlimit.o sandbox-systrace.o sandbox-darwin.o  sandbox-seccomp-filter.o sandbox-capsicum.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat  -lcrypto -ldl -lutil -lz  
/usr/bin/gcc -o ssh-add ssh-add.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keyscan ssh-keyscan.o roaming_dummy.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-keysign ssh-keysign.o readconf.o roaming_dummy.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-pkcs11-helper ssh-pkcs11-helper.o ssh-pkcs11.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o ssh-agent ssh-agent.o ssh-pkcs11-client.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o scp scp.o progressmeter.o bufaux.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sftp-server sftp-server.o sftp-common.o sftp-server-main.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz
/usr/bin/gcc -o sftp progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o -L. -Lopenbsd-compat/ -L/usr/contrib//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -lssh -lopenbsd-compat -lcrypto -ldl -lutil -lz 
BUILDDIR=`pwd`;  TEST_SSH_SCP="${BUILDDIR}/scp";  TEST_SSH_SSH="${BUILDDIR}/ssh";  TEST_SSH_SSHD="${BUILDDIR}/sshd";  TEST_SSH_SSHAGENT="${BUILDDIR}/ssh-agent";  TEST_SSH_SSHADD="${BUILDDIR}/ssh-add";  TEST_SSH_SSHKEYGEN="${BUILDDIR}/ssh-keygen";  TEST_SSH_SSHPKCS11HELPER="${BUILDDIR}/ssh-pkcs11-helper";  TEST_SSH_SSHKEYSCAN="${BUILDDIR}/ssh-keyscan";  TEST_SSH_SFTP="${BUILDDIR}/sftp";  TEST_SSH_SFTPSERVER="${BUILDDIR}/sftp-server";  TEST_SSH_PLINK="plink";  TEST_SSH_PUTTYGEN="puttygen";  TEST_SSH_CONCH="conch";  TEST_SSH_IPV6="yes" ;  TEST_SSH_ECC="yes" ;  cd ./regress || exit $?;  make  .OBJDIR="${BUILDDIR}/regress"  .CURDIR="`pwd`"  BUILDDIR="${BUILDDIR}"  OBJ="${BUILDDIR}/regress/"  PATH="${BUILDDIR}:${PATH}"  TEST_ENV=MALLOC_OPTIONS=""  TEST_SSH_SCP="${TEST_SSH_SCP}"  TEST_SSH_SSH="${TEST_SSH_SSH}"  TEST_SSH_SSHD="${TEST_SSH_SSHD}"  TEST_SSH_SSHAGENT="${TEST_SSH_SSHAGENT}"  TEST_SSH_SSHADD="${TEST_SSH_SSHADD}"  TEST_SSH_SSHKEYGEN="${TEST_SSH_SSHKEYGEN}"  TEST_SSH_SSHPKCS11HELPER="${TEST_SSH_SSHPKCS11HELPER}"  TEST_SSH_SSHKEYSCAN="${TEST_SSH_SSHKEYSCAN}"  TEST_SSH_SFTP="${TEST_SSH_SFTP}"  TEST_SSH_SFTPSERVER="${TEST_SSH_SFTPSERVER}"  TEST_SSH_PLINK="${TEST_SSH_PLINK}"  TEST_SSH_PUTTYGEN="${TEST_SSH_PUTTYGEN}"  TEST_SSH_CONCH="${TEST_SSH_CONCH}"  TEST_SSH_IPV6="${TEST_SSH_IPV6}"  TEST_SSH_ECC="${TEST_SSH_ECC}"  TEST_SHELL="sh"  EXEEXT=""  tests && echo all tests passed
test "x" = "x" || mkdir -p /usr/source/openssh-SNAP-20150314/regress//valgrind-out
set -e ; if test -z "" ; then  V="" ;  test "x" = "x" ||  V=/usr/source/openssh-SNAP-20150314/regress/valgrind-unit.sh ;  $V /usr/source/openssh-SNAP-20150314/regress/unittests/sshbuf/test_sshbuf ;  $V /usr/source/openssh-SNAP-20150314/regress/unittests/sshkey/test_sshkey  -d /usr/source/openssh-SNAP-20150314/regress/unittests/sshkey/testdata ;  $V /usr/source/openssh-SNAP-20150314/regress/unittests/bitmap/test_bitmap ;  $V /usr/source/openssh-SNAP-20150314/regress/unittests/kex/test_kex ;  $V /usr/source/openssh-SNAP-20150314/regress/unittests/hostkeys/test_hostkeys  -d /usr/source/openssh-SNAP-20150314/regress/unittests/hostkeys/testdata ;  fi
test_sshbuf: ................................................................................................... 100 tests ok
test_sshkey: .............................................................................................. 94 tests ok
test_bitmap: .. 2 tests ok
test_kex: ................................................................................................................................................................................................................................................................................................................................................................ 352 tests ok
test_hostkeys: .................. 18 tests ok
/usr/source/openssh-SNAP-20150314/ssh-keygen -if /usr/source/openssh-SNAP-20150314/regress/rsa_ssh2.prv | diff - /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.prv
tr '\n' '\r' </usr/source/openssh-SNAP-20150314/regress/rsa_ssh2.prv > /usr/source/openssh-SNAP-20150314/regress/rsa_ssh2_cr.prv
/usr/source/openssh-SNAP-20150314/ssh-keygen -if /usr/source/openssh-SNAP-20150314/regress/rsa_ssh2_cr.prv | diff - /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.prv
awk '{print $0 "\r"}' /usr/source/openssh-SNAP-20150314/regress/rsa_ssh2.prv > /usr/source/openssh-SNAP-20150314/regress/rsa_ssh2_crnl.prv
/usr/source/openssh-SNAP-20150314/ssh-keygen -if /usr/source/openssh-SNAP-20150314/regress/rsa_ssh2_crnl.prv | diff - /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.prv
cat /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.prv > /usr/source/openssh-SNAP-20150314/regress//t2.out
chmod 600 /usr/source/openssh-SNAP-20150314/regress//t2.out
/usr/source/openssh-SNAP-20150314/ssh-keygen -yf /usr/source/openssh-SNAP-20150314/regress//t2.out | diff - /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.pub
/usr/source/openssh-SNAP-20150314/ssh-keygen -ef /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.pub >/usr/source/openssh-SNAP-20150314/regress//t3.out
/usr/source/openssh-SNAP-20150314/ssh-keygen -if /usr/source/openssh-SNAP-20150314/regress//t3.out | diff - /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.pub
/usr/source/openssh-SNAP-20150314/ssh-keygen -E md5 -lf /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20150314/regress/t4.ok
/usr/source/openssh-SNAP-20150314/ssh-keygen -Bf /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20150314/regress/t5.ok
/usr/source/openssh-SNAP-20150314/ssh-keygen -if /usr/source/openssh-SNAP-20150314/regress/dsa_ssh2.prv > /usr/source/openssh-SNAP-20150314/regress//t6.out1
/usr/source/openssh-SNAP-20150314/ssh-keygen -if /usr/source/openssh-SNAP-20150314/regress/dsa_ssh2.pub > /usr/source/openssh-SNAP-20150314/regress//t6.out2
chmod 600 /usr/source/openssh-SNAP-20150314/regress//t6.out1
/usr/source/openssh-SNAP-20150314/ssh-keygen -yf /usr/source/openssh-SNAP-20150314/regress//t6.out1 | diff - /usr/source/openssh-SNAP-20150314/regress//t6.out2
/usr/source/openssh-SNAP-20150314/ssh-keygen -lf /usr/source/openssh-SNAP-20150314/regress//t7.out > /dev/null
/usr/source/openssh-SNAP-20150314/ssh-keygen -Bf /usr/source/openssh-SNAP-20150314/regress//t7.out > /dev/null
/usr/source/openssh-SNAP-20150314/ssh-keygen -lf /usr/source/openssh-SNAP-20150314/regress//t8.out > /dev/null
/usr/source/openssh-SNAP-20150314/ssh-keygen -Bf /usr/source/openssh-SNAP-20150314/regress//t8.out > /dev/null
test "yes" != yes ||  /usr/source/openssh-SNAP-20150314/ssh-keygen -lf /usr/source/openssh-SNAP-20150314/regress//t9.out > /dev/null
test "yes" != yes ||  /usr/source/openssh-SNAP-20150314/ssh-keygen -Bf /usr/source/openssh-SNAP-20150314/regress//t9.out > /dev/null
/usr/source/openssh-SNAP-20150314/ssh-keygen -lf /usr/source/openssh-SNAP-20150314/regress//t10.out > /dev/null
/usr/source/openssh-SNAP-20150314/ssh-keygen -Bf /usr/source/openssh-SNAP-20150314/regress//t10.out > /dev/null
/usr/source/openssh-SNAP-20150314/ssh-keygen -E sha256 -lf /usr/source/openssh-SNAP-20150314/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20150314/regress/t11.ok
/usr/source/openssh-SNAP-20150314/ssh-keygen -lf /usr/source/openssh-SNAP-20150314/regress//t12.out.pub | grep -q test-comment-1234
run test connect.sh ...
test: syntax error
test: syntax error
tset: standard error: Operation not supported

10:43AM  up 31 days,  9:17, 1 user, load averages: 5.10, 4.32, 4.15
USER     TTY FROM              LOGIN@  IDLE WHAT
doctor   p0  ts1p17.nl2k.ab.c 10:22AM    15 script
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sd0a      ufs   3.9G  1.9G  1.9G  50% /
/dev/sd0h      ufs    88G   65G   19G  78% /usr
/dev/sd0g      ufs    88G   33G   51G  40% /usr/var
/dev/sd0f      ufs    88G   69G   16G  82% /usr/home
mfs:27         mfs   992M  4.2M  939M   1% /tmp
Delete is backspace
/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
tset: standard error: Operation not supported

10:43AM  up 31 days,  9:17, 1 user, load averages: 5.09, 4.33, 4.15
USER     TTY FROM              LOGIN@  IDLE WHAT
doctor   p0  ts1p17.nl2k.ab.c 10:22AM    15 script
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sd0a      ufs   3.9G  1.9G  1.9G  50% /
/dev/sd0h      ufs    88G   65G   19G  78% /usr
/dev/sd0g      ufs    88G   33G   51G  40% /usr/var
/dev/sd0f      ufs    88G   69G   16G  82% /usr/home
mfs:27         mfs   992M  4.2M  939M   1% /tmp
Delete is backspace
/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
ok simple connect
run test proxy-connect.sh ...
test: syntax error
test: syntax error
plain username protocol 1 privsep=no comp=no
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 1 privsep=no comp=no
plain username protocol 1 privsep=no comp=yes
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 1 privsep=no comp=yes
plain username protocol 2 privsep=no comp=no
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 2 privsep=no comp=no
plain username protocol 2 privsep=no comp=yes
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 2 privsep=no comp=yes
plain username protocol 1 privsep=yes comp=no
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 1 privsep=yes comp=no
plain username protocol 1 privsep=yes comp=yes
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 1 privsep=yes comp=yes
plain username protocol 2 privsep=yes comp=no
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 2 privsep=yes comp=no
plain username protocol 2 privsep=yes comp=yes
tset: standard error: Operation not supported

/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
bad SSH_CONNECTION protocol 2 privsep=yes comp=yes
username with style protocol 1
tset: standard error: Operation not supported

10:43AM  up 31 days,  9:17, 1 user, load averages: 4.99, 4.34, 4.16
USER     TTY FROM              LOGIN@  IDLE WHAT
doctor   p0  ts1p17.nl2k.ab.c 10:22AM    15 script
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sd0a      ufs   3.9G  1.9G  1.9G  50% /
/dev/sd0h      ufs    88G   65G   19G  78% /usr
/dev/sd0g      ufs    88G   33G   51G  40% /usr/var
/dev/sd0f      ufs    88G   69G   16G  82% /usr/home
mfs:27         mfs   992M  4.2M  939M   1% /tmp
Delete is backspace
/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
username with style protocol 2
tset: standard error: Operation not supported

10:43AM  up 31 days,  9:17, 1 user, load averages: 4.99, 4.34, 4.16
USER     TTY FROM              LOGIN@  IDLE WHAT
doctor   p0  ts1p17.nl2k.ab.c 10:22AM    15 script
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sd0a      ufs   3.9G  1.9G  1.9G  50% /
/dev/sd0h      ufs    88G   65G   19G  78% /usr
/dev/sd0g      ufs    88G   33G   51G  40% /usr/var
/dev/sd0f      ufs    88G   69G   16G  82% /usr/home
mfs:27         mfs   992M  4.2M  939M   1% /tmp
Delete is backspace
/root/.bashrc: line 227: /usr/contrib/lib/news/bin/ctlinnd: No such file or directory
daemon: /var/news/etc/send-uucp: No such file or directory
failed proxy connect
*** Error code 1

Stop.
*** Error code 1

Stop.
You have new mail in /var/mail/doctor
doctor.nl2k.ab.ca//usr/source/openssh-SNAP-20150314$ x
sh: x: command not found
doctor.nl2k.ab.ca//usr/source/openssh-SNAP-20150314$ exit
exit

Script done on Fri Mar 13 10:43:35 2015


2)

Upgraded to the latest Tera Term and got this message when I install
openssh-SNAP-20140314:

A communications error occured while sending an SSH packet. The
connection will close. (WSAAsyncSelect1:10093)


-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
 Never compare your inside with somebody else's outside.  -Hugh Macleod

From ronf at timeheart.net  Sun Mar 15 09:12:49 2015
From: ronf at timeheart.net (Ron Frederick)
Date: Sat, 14 Mar 2015 15:12:49 -0700
Subject: Bug in ssh-keygen
Message-ID: <00D11C32-939B-4071-8BF9-CC8B14C25D13@timeheart.net>

Hello,

I just submitted bug 2366 in bugzilla with a proposed patch for a problem I found in sshkey.c having to do with decrypting new format private keys when attempting to use GCM ciphers. Here?s more info from my bug report:

I was trying out the new OpenSSH private key format and I ran into a problem when trying to work with keys encrypted in aes128-gcm and aes256-gcm format. While ssh-keygen encrypted these keys correctly, it was not able to decrypt them. I've identified the problem as an issue with the lengths it passes into cipher_crypt() when dealing with a cipher with integrated MAC support.

Steps to reproduce:

1) Create a new format key with a command like:
      ssh-keygen -t ed25519 -N test -Z aes128-gcm at openssh.com -f new_key

2) Attempt to decrypt this key with a command like:
      ssh-keygen -p -P test -N '' -f new_key

With OpenSSH 6.7p1, this fails with the error "Bad passphrase" for aes128-gcm and aes256-gcm, but works correctly for other ciphers which don't include a built-in MAC. The error happens for all key types when using the new private key format.

The error is in the call inside sshkey_parse_private2() where it passes in the length of the encrypted buffer:

        if ((r = cipher_crypt(&ciphercontext, 0, dp, sshbuf_ptr(decoded),
            sshbuf_len(decoded), 0, cipher_authlen(cipher))) != 0) {

The length here should be encrypted_len, not sshbuf_len(decoded), as that includes the cipher_authlen(cipher) additional MAC bytes.

A few additional changes are needed to use encrypted_len safely here and to later properly consume the auth data. I have attached a patch which I believe fixes this problem.

With the fix, step 2 above succeeds and properly decrypts the key created in step 1.

I hope this is helpful. Thanks for your time!
-- 
Ron Frederick
ronf at timeheart.net




From debian at jstimpfle.de  Mon Mar 16 01:48:30 2015
From: debian at jstimpfle.de (Jens Stimpfle)
Date: Sun, 15 Mar 2015 15:48:30 +0100
Subject: ssh -i option does not work properly with ssh-agent
Message-ID: <20150315144830.GA6430@jstimpfle.de>

Hi,

I noticed that the ssh -i <keyfile> option is "ignored" in my case:

On my server, I have two keys in .ssh/authorized_keys:

command="echo A" ssh-rsa A...  # Key A
command="echo B" ssh-rsa B...  # Key B

Suppose these keys are stored on my client as A{,.pub} and B{,.pub}. Now
the following situation:

$ ssh-add -L
ssh-rsa A...
$ ssh -i B server
A

As you can see, when A is loaded in ssh-agent but B isn't, the
connection is made with key A even when B is specifically requested.

I looked around the source and found a few hints here and there
(readconf.c:add_identity_files(), sshconnect2.c:pubkey_prepare(), the
"userprovided" tag in the Options struct...), but overall it's unclear
to me what the semantics of "-i" is actually meant to be.

What I always expected from "-i" was that only the keys given with -i
are tried, or at least these keys are tried first, irrespective of
whether or not they are loaded into ssh-agent.

I tried this with the versions from current Debian jessie, and also
compiled the developer version 8ef691 from 2015-03-11 and got the same
behaviour.

Many regards,
Jens Stimpfle

From lists at spuddy.org  Mon Mar 16 02:04:13 2015
From: lists at spuddy.org (Stephen Harris)
Date: Sun, 15 Mar 2015 11:04:13 -0400
Subject: ssh -i option does not work properly with ssh-agent
In-Reply-To: <20150315144830.GA6430@jstimpfle.de>
References: <20150315144830.GA6430@jstimpfle.de>
Message-ID: <20150315150413.GA30882@mercury.spuddy.org>

On Sun, Mar 15, 2015 at 03:48:30PM +0100, Jens Stimpfle wrote:
> I noticed that the ssh -i <keyfile> option is "ignored" in my case:

[...]

> As you can see, when A is loaded in ssh-agent but B isn't, the
> connection is made with key A even when B is specifically requested.

You didn't specify "only use B"

     IdentitiesOnly
             Specifies that ssh should only use the authentication identity
             files configured in the ssh_config files, even if the ssh-agent
             offers more identities.  The argument to this keyword must be
             "yes" or "no".  This option is intended for situations where
             ssh-agent offers many different identities.  The default is "no".


-- 

rgds
Stephen

From keisial at gmail.com  Mon Mar 16 08:52:54 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sun, 15 Mar 2015 22:52:54 +0100
Subject: ssh -i option does not work properly with ssh-agent
In-Reply-To: <20150315144830.GA6430@jstimpfle.de>
References: <20150315144830.GA6430@jstimpfle.de>
Message-ID: <5505FF36.50105@gmail.com>

On 15/03/15 15:48, Jens Stimpfle wrote:
> Hi,
>
> I noticed that the ssh -i<keyfile>  option is "ignored" in my case:
>
> On my server, I have two keys in .ssh/authorized_keys:
>
> command="echo A" ssh-rsa A...  # Key A
> command="echo B" ssh-rsa B...  # Key B
>
> Suppose these keys are stored on my client as A{,.pub} and B{,.pub}. Now
> the following situation:
>
> $ ssh-add -L
> ssh-rsa A...
> $ ssh -i B server
> A
>
> As you can see, when A is loaded in ssh-agent but B isn't, the
> connection is made with key A even when B is specifically requested.
>
> I looked around the source and found a few hints here and there
> (readconf.c:add_identity_files(), sshconnect2.c:pubkey_prepare(), the
> "userprovided" tag in the Options struct...), but overall it's unclear
> to me what the semantics of "-i" is actually meant to be.
>
> What I always expected from "-i" was that only the keys given with -i
> are tried, or at least these keys are tried first, irrespective of
> whether or not they are loaded into ssh-agent.

ssh tries with the ssh-agent keys first, then with the one provided with -i
As A is loaded and accepted, B is never tried.
I have been bitten by that several times, too. Usually when having many 
keys in the agent, and trying to use a specific key, just to be rejected 
by attempting a login with too-many-keys. I usually prepend env -i to 
the ssh command, to disconnect it from the agent. Although as Stephen 
mentions, you can also solve it with -o IdentitiesOnly=yes.

IMHO it should try -i keys first, and then the agent ones. But if the -i 
key is already in the agent, it would be preferable not to ask for its 
password again...


From sec at 42.org  Tue Mar 17 00:50:34 2015
From: sec at 42.org (Stefan `Sec` Zehl)
Date: Mon, 16 Mar 2015 14:50:34 +0100
Subject: OpenSSH (documentation) bug regarding RekeyLimit
Message-ID: <20150316135033.GA7984@ice.42.org>

Hi,

the OpenSSH documentation regarding "RekeyLimit" specifies:

|  RekeyLimit
|      Specifies the maximum amount of data that may be transmitted before
|      the session key is renegotiated, optionally followed a maximum
|      amount of time that may pass before the session key is
|      renegotiated. The first argument is specified in bytes and may have
|      a suffix of ?K?, ?M?, or ?G? to indicate Kilobytes, Megabytes, or
|      Gigabytes, respectively. The default is between ?1G? and ?4G?,
|      depending on the cipher.

Checking packet.c we see the following code:

|         /*
|          * The 2^(blocksize*2) limit is too expensive for 3DES,
|          * blowfish, etc, so enforce a 1GB limit for small blocksizes.
|          */
|         if (enc->block_size >= 16)
|                 *max_blocks = (u_int64_t)1 << (enc->block_size*2);
|         else
|                 *max_blocks = ((u_int64_t)1 << 30) / enc->block_size;

This makes the default RekeyLimit 2G bytes for "small" ciphers like
3des-cbc (which has an enc->block_size of 8).

On other ciphers like aes128-cbc which have a enc->blocksize of 16, this
makes max_blocks = 1 << 32, which is 4G blocks, or, to be more precise 
64G bytes.

Either this is an coding oversight (missing an "/ enc->block_size") or
the documentation is incorrect regarding the 4G limit.

CU,
    Sec
-- 
I think the IDE issue is a good point.  People with IDE hardware in
their machines should be punished by making them wait to boot...
                                               -- terry at lambert.org

From clabbe.montjoie at gmail.com  Tue Mar 17 02:34:47 2015
From: clabbe.montjoie at gmail.com (Corentin LABBE)
Date: Mon, 16 Mar 2015 16:34:47 +0100
Subject: [openssh with openssl cryptodev engine] sshd killed by seccomp
 filter
In-Reply-To: <54EE47AA.1050209@gmail.com>
References: <20150225130918.GA21519@Red>
 <alpine.BSO.2.11.1502260419500.5972@natsu.mindrot.org>
 <54EE47AA.1050209@gmail.com>
Message-ID: <5506F817.90904@gmail.com>

On 02/25/15 23:07, ?ngel Gonz?lez wrote:
> On 25/02/15 18:21, Damien Miller wrote:
>> On Wed, 25 Feb 2015, LABBE Corentin wrote:
>>> +    SC_ALLOW(ioctl),
>> no, sorry. ioctl is too much attack kernel surface and would defeat the
>> usefulness of the sandbox.
>>
>> -d
> Labbe, which ioctl is being issued?
> 

Lots of differents ioctl, but nothing standard, there are used only by the cryptodev module.

example:
ioctl(ctx->cfd, CIOCGSESSION, &ctx->sess)
ioctl(ctx->cfd, CIOCFSESSION, &ctx->sess.ses)
ioctl(ctx->cfd, CIOCAUTHCRYPT, &cryp)
ioctl(ctx->cfd, CIOCCRYPT, &cryp)

Regards


From sec at 42.org  Tue Mar 17 04:38:55 2015
From: sec at 42.org (Stefan `Sec` Zehl)
Date: Mon, 16 Mar 2015 18:38:55 +0100
Subject: OpenSSH (documentation) bug regarding RekeyLimit
In-Reply-To: <20150316135033.GA7984@ice.42.org>
References: <20150316135033.GA7984@ice.42.org>
Message-ID: <20150316173855.GA38634@ice.42.org>

Hi,

Starting off my first mail with an ebarassing typo...

On Mon, Mar 16, 2015 at 14:50 +0100, Stefan `Sec` Zehl wrote:
> This makes the default RekeyLimit 2G bytes for "small" ciphers like
> 3des-cbc (which has an enc->block_size of 8).

Of course I meant "1G" in this paragraph, not 2G.

CU,
    Sec
-- 
I know I've got it great, really, good job, good friends, loving family,
total freedom, and long bubblebaths. what else could there be? 

From pkay at xs4all.nl  Tue Mar 17 04:57:44 2015
From: pkay at xs4all.nl (PK)
Date: Mon, 16 Mar 2015 18:57:44 +0100
Subject: [Fwd: sftp client recursively copy files and folders]
Message-ID: <575265072b25be0a09c87293e5dde004.squirrel@webmail.xs4all.nl>

A very good afternoon

I would like to use the latest sftp client which supports "sftp> put -r"
parameter command for "Recursively copy files and directories" in order to
transfer files a lot easier.

I noticed the latest sftp client (5.3p1-104.1) was released on 'Thu Nov 06
2014'. Could you please tell me what the current stable release is and how
i can obtain it?

I'm looking forward in reading your reply and
Thanks in advance,


sftp client version:    SFTP protocol version 3
server os/verion:       CentOS release 6.6 (Final)

LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
cpe:/o:centos:linux:6:GA






From djm at mindrot.org  Tue Mar 17 10:59:35 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 17 Mar 2015 10:59:35 +1100 (AEDT)
Subject: [Fwd: sftp client recursively copy files and folders]
In-Reply-To: <575265072b25be0a09c87293e5dde004.squirrel@webmail.xs4all.nl>
References: <575265072b25be0a09c87293e5dde004.squirrel@webmail.xs4all.nl>
Message-ID: <alpine.BSO.2.11.1503171057420.7079@natsu.mindrot.org>

On Mon, 16 Mar 2015, PK wrote:

> A very good afternoon
> 
> I would like to use the latest sftp client which supports "sftp> put -r"
> parameter command for "Recursively copy files and directories" in order to
> transfer files a lot easier.
> 
> I noticed the latest sftp client (5.3p1-104.1) was released on 'Thu Nov 06
> 2014'. Could you please tell me what the current stable release is and how
> i can obtain it?

Our stable version can be found at http://www.openssh.com/ and is 6.7p1

5.3p1 was released over 5 years ago. Your vendor is shipping ancient
software.

-d

From dirkx at webweaving.org  Tue Mar 17 23:55:00 2015
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Tue, 17 Mar 2015 13:55:00 +0100
Subject: [patch] Updated patch for pkcs#11 smartcard readers that have a
 protected PIN path
Message-ID: <2AA8AAA7-FD5A-4C22-9EEE-F0D9D08CD6EB@webweaving.org>

Some smartcard readers have keypad to enter the PIN securely (i.e. such that it cannot be intercepted by a rogue (ssh) binary. 

PKCS#11 allows for enforcing this in hardware. Below patch allows for SSH to make use of this; against head/master as of today.

Dw.


commit 7f0250a8ae6c639a19d4e1e24fc112d5e2e1249a
Author: Dirk-Willem van Gulik <dirkx at webweaving.org>
Date:   Tue Mar 17 13:41:31 2015 +0100

    Ensuring support for PINs that can only be entered on a secure keypad (CKF_PROTECTED_AUTHENTICATION_PATH)

diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
index c3a112f..b053332 100644
--- a/ssh-pkcs11.c
+++ b/ssh-pkcs11.c
@@ -255,22 +255,30 @@ pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
 	si = &k11->provider->slotinfo[k11->slotidx];
 	if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
 		if (!pkcs11_interactive) {
-			error("need pin");
+			error("need pin%s", 
+				(si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) 
+					? " entry on reader keypad" : "");
 			return (-1);
 		}
-		snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
-		    si->token.label);
-		pin = read_passphrase(prompt, RP_ALLOW_EOF);
-		if (pin == NULL)
-			return (-1);	/* bail out */
+		if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) {
+			verbose("Deferring PIN entry to keypad of chipcard reader.");
+			pin = NULL;
+		} else {
+			snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
+				si->token.label);
+			pin = read_passphrase(prompt, RP_ALLOW_EOF);
+			if (pin == NULL)
+				return (-1);    /* bail out */
+               };
+
 		rv = f->C_Login(si->session, CKU_USER,
 		    (u_char *)pin, pin ? strlen(pin) : 0);
 		if (rv != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN) {
-			free(pin);
+			if (pin) free(pin);
 			error("C_Login failed: %lu", rv);
 			return (-1);
 		}
-		free(pin);
+		if (pin) free(pin);
 		si->logged_in = 1;
 	}
 	key_filter[1].pValue = k11->keyid;


From abhi.dhiman83 at gmail.com  Wed Mar 18 01:52:23 2015
From: abhi.dhiman83 at gmail.com (abhi dhiman)
Date: Tue, 17 Mar 2015 20:22:23 +0530
Subject: Fix for CVE-2014-1692 , CVE-2014-2532
Message-ID: <CAOP+oMPLCzO56GNxkSBxF5o34sQAwJnLWDxskn=8QYorggqBbQ@mail.gmail.com>

Hi All,

Actually I am working with the OpenSSH version 6.2p which is vulnerable to
above mentioned vulnerabilities.

So am looking for some help how I can fix these vulnerabilities in my
version. I need to fix it in the OpenSSH code.

Regards
Abhishek

From dirkx at webweaving.org  Wed Mar 18 03:41:05 2015
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Tue, 17 Mar 2015 17:41:05 +0100
Subject: Locking down a specific Identity on a smartcard
Message-ID: <DCEB8279-13F8-4A64-A80B-4E97DDFE5BF6@webweaving.org>

Using a ~/.ssh/config such as:

	Host ...
		IdentitiesOnly	yes
		IdentityFile	?. file ?

one can limit/precisely control what Identities are flashed at the server. 

Which can be useful in settings where it is desirable to not (be forced) show ?what you have?; which is increasingly of interest; especially in environment where the keys are somewhat fleeting and one does not quite own the stack all the way down to the board.

One can do the same with:

	Host ...
		PKCS11Provider 	/.../opensc-pkcs11.so 
		IdentitiesOnly	yes
		IdentityFile	/tmp/null

to lock things down to a smartcart. 

Or rather, to all smartcards/PKCS11 provided keys on the system (all are then tried). 

Below patch allows for specifications such as:

	PKCS11Provider 	c00d71ce3be7ebf2960aa5efc7fb5a841713280a@/Library/OpenSC/lib/opensc-pkcs11.so 
	IdentitiesOnly	yes
	IdentityFile	/tmp/null

where there PKCS11Provider is <keyid> @ <path to DLL>; and <keyid> is the one as per PKCS11; along with a few tweaks
in the verbose/debug output which makes it easier to understand what is (not) happening in the case of PKCS11.

So one can lock things down a bit better; and PKCS11Provider can be repeated at global and at per-host level*. 

Is that a workable syntax ? Or a really bad idea (I found the alternative (my first attempt): overloading the IdentityFile is messier; as PKCS11Provider is sort of a special IdentityFile in itself).

Would love to hear folks their thoughts.

Dw.

*: This also allows for things such as smartcards with multiple keys; some protected by a PIN which can only be entered in HW, some allowing a keyboard entered PIN and some without it; useful in combination with command=.


diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
index b053332..246c61b 100644
--- a/ssh-pkcs11.c
+++ b/ssh-pkcs11.c
@@ -193,27 +193,28 @@ static int
 pkcs11_find(struct pkcs11_provider *p, CK_ULONG slotidx, CK_ATTRIBUTE *attr,
     CK_ULONG nattr, CK_OBJECT_HANDLE *obj)
 {
 	CK_FUNCTION_LIST	*f;
 	CK_SESSION_HANDLE	session;
 	CK_ULONG		nfound = 0;
 	CK_RV			rv;
 	int			ret = -1;
 
 	f = p->function_list;
 	session = p->slotinfo[slotidx].session;
 	if ((rv = f->C_FindObjectsInit(session, attr, nattr)) != CKR_OK) {
 		error("C_FindObjectsInit failed (nattr %lu): %lu", nattr, rv);
 		return (-1);
 	}
 	if ((rv = f->C_FindObjects(session, obj, 1, &nfound)) != CKR_OK ||
 	    nfound != 1) {
 		debug("C_FindObjects failed (nfound %lu nattr %lu): %lu",
 		    nfound, nattr, rv);
 	} else
 		ret = 0;
 	if ((rv = f->C_FindObjectsFinal(session)) != CKR_OK)
 		error("C_FindObjectsFinal failed: %lu", rv);
+
 	return (ret);
 }
 
 /* openssl callback doing the actual signing operation */
@@ -221,83 +222,88 @@ static int
 pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
     int padding)
 {
 	struct pkcs11_key	*k11;
 	struct pkcs11_slotinfo	*si;
 	CK_FUNCTION_LIST	*f;
 	CK_OBJECT_HANDLE	obj;
 	CK_ULONG		tlen = 0;
 	CK_RV			rv;
 	CK_OBJECT_CLASS	private_key_class = CKO_PRIVATE_KEY;
 	CK_BBOOL		true_val = CK_TRUE;
 	CK_MECHANISM		mech = {
 		CKM_RSA_PKCS, NULL_PTR, 0
 	};
 	CK_ATTRIBUTE		key_filter[] = {
 		{CKA_CLASS, NULL, sizeof(private_key_class) },
 		{CKA_ID, NULL, 0},
 		{CKA_SIGN, NULL, sizeof(true_val) }
 	};
 	char			*pin, prompt[1024];
 	int			rval = -1;
 
 	key_filter[0].pValue = &private_key_class;
 	key_filter[2].pValue = &true_val;
 
 	if ((k11 = RSA_get_app_data(rsa)) == NULL) {
 		error("RSA_get_app_data failed for rsa %p", rsa);
 		return (-1);
 	}
 	if (!k11->provider || !k11->provider->valid) {
 		error("no pkcs11 (valid) provider for rsa %p", rsa);
 		return (-1);
 	}
 	f = k11->provider->function_list;
 	si = &k11->provider->slotinfo[k11->slotidx];
+
 	if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
 		if (!pkcs11_interactive) {
 			error("need pin%s", 
 				(si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) 
 					? " entry on reader keypad" : "");
 			return (-1);
 		}
 		if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) {
 			verbose("Deferring PIN entry to keypad of chipcard reader.");
 			pin = NULL;
 		} else {
 			snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
 				si->token.label);
 			pin = read_passphrase(prompt, RP_ALLOW_EOF);
 			if (pin == NULL)
 				return (-1);    /* bail out */
                };
 
 		rv = f->C_Login(si->session, CKU_USER,
-		    (u_char *)pin, strlen(pin));
+		    (u_char *)pin, pin ? strlen(pin) : 0);
+
 		if (rv != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN) {
 			if (pin) free(pin);
 			error("C_Login failed: %lu", rv);
 			return (-1);
 		}
 		if (pin) free(pin);
 		si->logged_in = 1;
 	}
 	key_filter[1].pValue = k11->keyid;
 	key_filter[1].ulValueLen = k11->keyid_len;
+
 	/* try to find object w/CKA_SIGN first, retry w/o */
 	if (pkcs11_find(k11->provider, k11->slotidx, key_filter, 3, &obj) < 0 &&
 	    pkcs11_find(k11->provider, k11->slotidx, key_filter, 2, &obj) < 0) {
-		error("cannot find private key");
+		char * hexid = tohex(k11->keyid,k11->keyid_len);
+		error("cannot find pkcs private key id %s",  hexid);
+		free(hexid);
 	} else if ((rv = f->C_SignInit(si->session, &mech, obj)) != CKR_OK) {
 		error("C_SignInit failed: %lu", rv);
 	} else {
 		/* XXX handle CKR_BUFFER_TOO_SMALL */
 		tlen = RSA_size(rsa);
 		rv = f->C_Sign(si->session, (CK_BYTE *)from, flen, to, &tlen);
 		if (rv == CKR_OK) 
 			rval = tlen;
 		else 
 			error("C_Sign failed: %lu", rv);
 	}
 	return (rval);
 }
 
@@ -402,32 +408,34 @@ static int
 pkcs11_fetch_keys(struct pkcs11_provider *p, CK_ULONG slotidx,
     struct sshkey ***keysp, int *nkeys)
 {
 	CK_OBJECT_CLASS	pubkey_class = CKO_PUBLIC_KEY;
 	CK_OBJECT_CLASS	cert_class = CKO_CERTIFICATE;
 	CK_ATTRIBUTE		pubkey_filter[] = {
 		{ CKA_CLASS, NULL, sizeof(pubkey_class) }
 	};
 	CK_ATTRIBUTE		cert_filter[] = {
 		{ CKA_CLASS, NULL, sizeof(cert_class) }
 	};
 	CK_ATTRIBUTE		pubkey_attribs[] = {
 		{ CKA_ID, NULL, 0 },
 		{ CKA_MODULUS, NULL, 0 },
-		{ CKA_PUBLIC_EXPONENT, NULL, 0 }
+		{ CKA_PUBLIC_EXPONENT, NULL, 0 },
+		{ CKA_LABEL, NULL, 0 }
 	};
 	CK_ATTRIBUTE		cert_attribs[] = {
 		{ CKA_ID, NULL, 0 },
 		{ CKA_SUBJECT, NULL, 0 },
-		{ CKA_VALUE, NULL, 0 }
+		{ CKA_VALUE, NULL, 0 },
+		{ CKA_LABEL, NULL, 0 }
 	};
 	pubkey_filter[0].pValue = &pubkey_class;
 	cert_filter[0].pValue = &cert_class;
 
 	if (pkcs11_fetch_keys_filter(p, slotidx, pubkey_filter, pubkey_attribs,
 	    keysp, nkeys) < 0 ||
 	    pkcs11_fetch_keys_filter(p, slotidx, cert_filter, cert_attribs,
 	    keysp, nkeys) < 0)
 		return (-1);
 	return (0);
 }
 
@@ -444,112 +452,132 @@ pkcs11_key_included(struct sshkey ***keysp, int *nkeys, struct sshkey *key)
 
 static int
 pkcs11_fetch_keys_filter(struct pkcs11_provider *p, CK_ULONG slotidx,
-    CK_ATTRIBUTE filter[], CK_ATTRIBUTE attribs[3],
+    CK_ATTRIBUTE filter[], CK_ATTRIBUTE attribs[4],
     struct sshkey ***keysp, int *nkeys)
 {
 	struct sshkey		*key;
 	RSA			*rsa;
 	X509 			*x509;
 	EVP_PKEY		*evp;
 	int			i;
 	const u_char		*cp;
 	CK_RV			rv;
 	CK_OBJECT_HANDLE	obj;
 	CK_ULONG		nfound;
 	CK_SESSION_HANDLE	session;
 	CK_FUNCTION_LIST	*f;
 
 	f = p->function_list;
 	session = p->slotinfo[slotidx].session;
 	/* setup a filter the looks for public keys */
 	if ((rv = f->C_FindObjectsInit(session, filter, 1)) != CKR_OK) {
 		error("C_FindObjectsInit failed: %lu", rv);
 		return (-1);
 	}
 	while (1) {
-		/* XXX 3 attributes in attribs[] */
-		for (i = 0; i < 3; i++) {
+		/* XXX 4 attributes in attribs[] */
+		for (i = 0; i < 4; i++) {
 			attribs[i].pValue = NULL;
 			attribs[i].ulValueLen = 0;
 		}
 		if ((rv = f->C_FindObjects(session, &obj, 1, &nfound)) != CKR_OK
 		    || nfound == 0)
 			break;
 		/* found a key, so figure out size of the attributes */
-		if ((rv = f->C_GetAttributeValue(session, obj, attribs, 3))
+		if ((rv = f->C_GetAttributeValue(session, obj, attribs, 4))
 		    != CKR_OK) {
 			error("C_GetAttributeValue failed: %lu", rv);
 			continue;
 		}
-		/* check that none of the attributes are zero length */
+		/* check that none of the attributes that matter are zero length */
 		if (attribs[0].ulValueLen == 0 ||
 		    attribs[1].ulValueLen == 0 ||
 		    attribs[2].ulValueLen == 0) {
 			continue;
 		}
 		/* allocate buffers for attributes */
-		for (i = 0; i < 3; i++)
+		for (i = 0; i < 4; i++)
 			attribs[i].pValue = xmalloc(attribs[i].ulValueLen);
 		/*
 		 * retrieve ID, modulus and public exponent of RSA key,
 		 * or ID, subject and value for certificates.
 		 */
 		rsa = NULL;
-		if ((rv = f->C_GetAttributeValue(session, obj, attribs, 3))
+		if ((rv = f->C_GetAttributeValue(session, obj, attribs, 4))
 		    != CKR_OK) {
 			error("C_GetAttributeValue failed: %lu", rv);
 		} else if (attribs[1].type == CKA_MODULUS ) {
 			if ((rsa = RSA_new()) == NULL) {
 				error("RSA_new failed");
 			} else {
 				rsa->n = BN_bin2bn(attribs[1].pValue,
 				    attribs[1].ulValueLen, NULL);
 				rsa->e = BN_bin2bn(attribs[2].pValue,
 				    attribs[2].ulValueLen, NULL);
 			}
 		} else {
 			cp = attribs[2].pValue;
 			if ((x509 = X509_new()) == NULL) {
 				error("X509_new failed");
 			} else if (d2i_X509(&x509, &cp, attribs[2].ulValueLen)
 			    == NULL) {
 				error("d2i_X509 failed");
 			} else if ((evp = X509_get_pubkey(x509)) == NULL ||
 			    evp->type != EVP_PKEY_RSA ||
 			    evp->pkey.rsa == NULL) {
 				debug("X509_get_pubkey failed or no rsa");
 			} else if ((rsa = RSAPublicKey_dup(evp->pkey.rsa))
 			    == NULL) {
 				error("RSAPublicKey_dup");
 			}
 			if (x509)
 				X509_free(x509);
 		}
 		if (rsa && rsa->n && rsa->e &&
 		    pkcs11_rsa_wrap(p, slotidx, &attribs[0], rsa) == 0) {
 			key = sshkey_new(KEY_UNSPEC);
 			key->rsa = rsa;
 			key->type = KEY_RSA;
 			key->flags |= SSHKEY_FLAG_EXT;
+
+			char * hex = tohex(attribs[0].pValue, (int) attribs[0].ulValueLen);
+
+			char label[128 + 2 + 3 + 1] = "";
+			if (attribs[3].ulValueLen > 0) {
+				unsigned long len = MIN(128, attribs[3].ulValueLen);
+
+				strcat(label," <");
+				strncpy(label+2, attribs[3].pValue, len);
+				if (len == 128) 
+					strcat(label,"...");
+				strcat(label,">");
+			};
+
 			if (pkcs11_key_included(keysp, nkeys, key)) {
+				debug("Ignorng key  %s%s (%p), already included", hex, label, key);
 				sshkey_free(key);
+			}
+			else if (index(p->name,'@') && strncmp(hex,p->name,strlen(hex))) {
+				debug("Ignoring key  %s%s (%p), not explicitly listed", hex, label, key);
 			} else {
 				/* expand key array and add key */
 				*keysp = xrealloc(*keysp, *nkeys + 1,
 				    sizeof(struct sshkey *));
 				(*keysp)[*nkeys] = key;
 				*nkeys = *nkeys + 1;
-				debug("have %d keys", *nkeys);
+
+				debug("Key %d: %s%s (%p)", *nkeys, hex, label, key);
 			}
+			free(hex);
 		} else if (rsa) {
 			RSA_free(rsa);
 		}
-		for (i = 0; i < 3; i++)
+		for (i = 0; i < 4; i++)
 			free(attribs[i].pValue);
 	}
 	if ((rv = f->C_FindObjectsFinal(session)) != CKR_OK)
 		error("C_FindObjectsFinal failed: %lu", rv);
 	return (0);
 }
 
 /* register a new provider, fails if provider already exists */
@@ -557,96 +585,101 @@ int
 pkcs11_add_provider(char *provider_id, char *pin, struct sshkey ***keyp)
 {
 	int nkeys, need_finalize = 0;
 	struct pkcs11_provider *p = NULL;
 	void *handle = NULL;
 	CK_RV (*getfunctionlist)(CK_FUNCTION_LIST **);
 	CK_RV rv;
 	CK_FUNCTION_LIST *f = NULL;
 	CK_TOKEN_INFO *token;
 	CK_ULONG i;
+	char *dll_filename = provider_id;
 
 	*keyp = NULL;
 	if (pkcs11_provider_lookup(provider_id) != NULL) {
 		error("provider already registered: %s", provider_id);
 		goto fail;
 	}
+
+	if (index(provider_id,'@'))
+		dll_filename = index(provider_id,'@') + 1;
+
 	/* open shared pkcs11-libarary */
-	if ((handle = dlopen(provider_id, RTLD_NOW)) == NULL) {
+	if ((handle = dlopen(dll_filename, RTLD_NOW)) == NULL) {
 		error("dlopen %s failed: %s", provider_id, dlerror());
 		goto fail;
 	}
 	if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
 		error("dlsym(C_GetFunctionList) failed: %s", dlerror());
 		goto fail;
 	}
 	p = xcalloc(1, sizeof(*p));
 	p->name = xstrdup(provider_id);
 	p->handle = handle;
 	/* setup the pkcs11 callbacks */
 	if ((rv = (*getfunctionlist)(&f)) != CKR_OK) {
 		error("C_GetFunctionList failed: %lu", rv);
 		goto fail;
 	}
 	p->function_list = f;
 	if ((rv = f->C_Initialize(NULL)) != CKR_OK) {
 		error("C_Initialize failed: %lu", rv);
 		goto fail;
 	}
 	need_finalize = 1;
 	if ((rv = f->C_GetInfo(&p->info)) != CKR_OK) {
 		error("C_GetInfo failed: %lu", rv);
 		goto fail;
 	}
 	rmspace(p->info.manufacturerID, sizeof(p->info.manufacturerID));
 	rmspace(p->info.libraryDescription, sizeof(p->info.libraryDescription));
 	debug("manufacturerID <%s> cryptokiVersion %d.%d"
 	    " libraryDescription <%s> libraryVersion %d.%d",
 	    p->info.manufacturerID,
 	    p->info.cryptokiVersion.major,
 	    p->info.cryptokiVersion.minor,
 	    p->info.libraryDescription,
 	    p->info.libraryVersion.major,
 	    p->info.libraryVersion.minor);
 	if ((rv = f->C_GetSlotList(CK_TRUE, NULL, &p->nslots)) != CKR_OK) {
 		error("C_GetSlotList failed: %lu", rv);
 		goto fail;
 	}
 	if (p->nslots == 0) {
 		error("no slots");
 		goto fail;
 	}
 	p->slotlist = xcalloc(p->nslots, sizeof(CK_SLOT_ID));
 	if ((rv = f->C_GetSlotList(CK_TRUE, p->slotlist, &p->nslots))
 	    != CKR_OK) {
 		error("C_GetSlotList failed: %lu", rv);
 		goto fail;
 	}
 	p->slotinfo = xcalloc(p->nslots, sizeof(struct pkcs11_slotinfo));
 	p->valid = 1;
 	nkeys = 0;
 	for (i = 0; i < p->nslots; i++) {
 		token = &p->slotinfo[i].token;
 		if ((rv = f->C_GetTokenInfo(p->slotlist[i], token))
 		    != CKR_OK) {
 			error("C_GetTokenInfo failed: %lu", rv);
 			continue;
 		}
 		rmspace(token->label, sizeof(token->label));
 		rmspace(token->manufacturerID, sizeof(token->manufacturerID));
 		rmspace(token->model, sizeof(token->model));
 		rmspace(token->serialNumber, sizeof(token->serialNumber));
 		debug("label <%s> manufacturerID <%s> model <%s> serial <%s>"
 		    " flags 0x%lx",
 		    token->label, token->manufacturerID, token->model,
 		    token->serialNumber, token->flags);
 		/* open session, login with pin and retrieve public keys */
 		if (pkcs11_open_session(p, i, pin) == 0)
 			pkcs11_fetch_keys(p, i, keyp, &nkeys);
 	}
 	if (nkeys > 0) {
 		TAILQ_INSERT_TAIL(&pkcs11_providers, p, next);
 		p->refcount++;	/* add to provider list */
 		return (nkeys);
 	}
 	error("no keys");
 	/* don't add the provider, since it does not have any keys */
diff --git a/sshconnect2.c b/sshconnect2.c
index ba56f64..fd664b1 100644
--- a/sshconnect2.c
+++ b/sshconnect2.c
@@ -1319,54 +1319,54 @@ int
 userauth_pubkey(Authctxt *authctxt)
 {
 	Identity *id;
 	int sent = 0;
 
 	while ((id = TAILQ_FIRST(&authctxt->keys))) {
 		if (id->tried++)
 			return (0);
 		/* move key to the end of the queue */
 		TAILQ_REMOVE(&authctxt->keys, id, next);
 		TAILQ_INSERT_TAIL(&authctxt->keys, id, next);
 		/*
 		 * send a test message if we have the public key. for
 		 * encrypted keys we cannot do this and have to load the
 		 * private key instead
 		 */
 		if (id->key != NULL) {
 			if (key_type_plain(id->key->type) == KEY_RSA &&
 			    (datafellows & SSH_BUG_RSASIGMD5) != 0) {
 				debug("Skipped %s key %s for RSA/MD5 server",
 				    key_type(id->key), id->filename);
 			} else if (id->key->type != KEY_RSA1) {
-				debug("Offering %s public key: %s",
-				    key_type(id->key), id->filename);
+				debug("Offering %s public key: %s (%p)",
+				    key_type(id->key), id->filename, id->key);
 				sent = send_pubkey_test(authctxt, id);
 			}
 		} else {
 			debug("Trying private key: %s", id->filename);
 			id->key = load_identity_file(id->filename,
 			    id->userprovided);
 			if (id->key != NULL) {
 				id->isprivate = 1;
 				if (key_type_plain(id->key->type) == KEY_RSA &&
 				    (datafellows & SSH_BUG_RSASIGMD5) != 0) {
 					debug("Skipped %s key %s for RSA/MD5 "
 					    "server", key_type(id->key),
 					    id->filename);
 				} else {
 					sent = sign_and_send_pubkey(
 					    authctxt, id);
 				}
 				key_free(id->key);
 				id->key = NULL;
 			}
 		}
 		if (sent)
 			return (sent);
 	}
 	return (0);
 }
 
 /*
  * Send userauth request message specifying keyboard-interactive method.
  */



From keisial at gmail.com  Wed Mar 18 08:55:14 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Tue, 17 Mar 2015 22:55:14 +0100
Subject: Fix for CVE-2014-1692 , CVE-2014-2532
In-Reply-To: <CAOP+oMPLCzO56GNxkSBxF5o34sQAwJnLWDxskn=8QYorggqBbQ@mail.gmail.com>
References: <CAOP+oMPLCzO56GNxkSBxF5o34sQAwJnLWDxskn=8QYorggqBbQ@mail.gmail.com>
Message-ID: <5508A2C2.9020608@gmail.com>

On 17/03/15 15:52, abhi dhiman wrote:
> Hi All,
>
> Actually I am working with the OpenSSH version 6.2p which is vulnerable to
> above mentioned vulnerabilities.
>
> So am looking for some help how I can fix these vulnerabilities in my
> version. I need to fix it in the OpenSSH code.
>
> Regards
> Abhishek
Unless you specifically enabled the experimental JPAKE support in 
openssh (eg. by adding

-DJPAKE in Makefile.inc) you are not affected by CVE-2014-1692.

In order to avoid CVE-2014-2532, you can apply this change:
https://anongit.mindrot.org/openssh.git/commit/?id=8569eba5d7f7348ce3955eeeb399f66f25c52ece

Regards



From djm at cvs.openbsd.org  Wed Mar 18 17:56:51 2015
From: djm at cvs.openbsd.org (Damien Miller)
Date: Wed, 18 Mar 2015 00:56:51 -0600 (MDT)
Subject: Announce: OpenSSH 6.8 released
Message-ID: <10945977882619878079.enqueue@cvs.openbsd.org>

OpenSSH 6.8 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.7
=========================

This is a major release, containing a number of new features as
well as a large internal re-factoring.

Potentially-incompatible changes
--------------------------------

 * sshd(8): UseDNS now defaults to 'no'. Configurations that match
   against the client host name (via sshd_config or authorized_keys)
   may need to re-enable it or convert to matching against addresses.

New Features
------------

 * Much of OpenSSH's internal code has been re-factored to be more
   library-like. These changes are mostly not user-visible, but
   have greatly improved OpenSSH's testability and internal layout.

 * Add FingerprintHash option to ssh(1) and sshd(8), and equivalent
   command-line flags to the other tools to control algorithm used
   for key fingerprints. The default changes from MD5 to SHA256 and
   format from hex to base64.

   Fingerprints now have the hash algorithm prepended. An example of
   the new format: SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE
   Please note that visual host keys will also be different.

 * ssh(1), sshd(8): Experimental host key rotation support. Add a
   protocol extension for a server to inform a client of all its
   available host keys after authentication has completed. The client
   may record the keys in known_hosts, allowing it to upgrade to better
   host key algorithms and a server to gracefully rotate its keys.

   The client side of this is controlled by a UpdateHostkeys config
   option (default off).

 * ssh(1): Add a ssh_config HostbasedKeyType option to control which
   host public key types are tried during host-based authentication.

 * ssh(1), sshd(8): fix connection-killing host key mismatch errors
   when sshd offers multiple ECDSA keys of different lengths.

 * ssh(1): when host name canonicalisation is enabled, try to
   parse host names as addresses before looking them up for
   canonicalisation. fixes bz#2074 and avoiding needless DNS
   lookups in some cases.

 * ssh-keygen(1), sshd(8): Key Revocation Lists (KRLs) no longer
   require OpenSSH to be compiled with OpenSSL support.

 * ssh(1), ssh-keysign(8): Make ed25519 keys work for host based
   authentication.

 * sshd(8): SSH protocol v.1 workaround for the Meyer, et al,
   Bleichenbacher Side Channel Attack. Fake up a bignum key before
   RSA decryption.

 * sshd(8): Remember which public keys have been used for
   authentication and refuse to accept previously-used keys.
   This allows AuthenticationMethods=publickey,publickey to require
   that users authenticate using two _different_ public keys.

 * sshd(8): add sshd_config HostbasedAcceptedKeyTypes and
   PubkeyAcceptedKeyTypes options to allow sshd to control what
   public key types will be accepted. Currently defaults to all.

 * sshd(8): Don't count partial authentication success as a failure
   against MaxAuthTries.

 * ssh(1): Add RevokedHostKeys option for the client to allow
   text-file or KRL-based revocation of host keys.

 * ssh-keygen(1), sshd(8): Permit KRLs that revoke certificates by
   serial number or key ID without scoping to a particular CA.

 * ssh(1): Add a "Match canonical" criteria that allows ssh_config
   Match blocks to trigger only in the second config pass.

 * ssh(1): Add a -G option to ssh that causes it to parse its
   configuration and dump the result to stdout, similar to "sshd -T".

 * ssh(1): Allow Match criteria to be negated. E.g. "Match !host".

 * The regression test suite has been extended to cover more OpenSSH
   features. The unit tests have been expanded and now cover key
   exchange.

Bugfixes

 * ssh-keyscan(1): ssh-keyscan has been made much more robust again
   servers that hang or violate the SSH protocol.

 * ssh(1), ssh-keygen(1): Fix regression bz#2306: Key path names were
   being lost as comment fields.

 * ssh(1): Allow ssh_config Port options set in the second config
   parse phase to be applied (they were being ignored). bz#2286

 * ssh(1): Tweak config re-parsing with host canonicalisation - make
   the second pass through the config files always run when host name
   canonicalisation is enabled (and not whenever the host name
   changes) bz#2267

 * ssh(1): Fix passing of wildcard forward bind addresses when
   connection multiplexing is in use; bz#2324;

 * ssh-keygen(1): Fix broken private key conversion from non-OpenSSH
   formats; bz#2345.

 * ssh-keygen(1): Fix KRL generation bug when multiple CAs are in
   use.

 * Various fixes to manual pages: bz#2288, bz#2316, bz#2273

Portable OpenSSH

 * Support --without-openssl at configure time

   Disables and removes dependency on OpenSSL. Many features,
   including SSH protocol 1 are not supported and the set of crypto
   options is greatly restricted. This will only work on systems
   with native arc4random or /dev/urandom.

   Considered highly experimental for now.

 * Support --without-ssh1 option at configure time

   Allows disabling support for SSH protocol 1.

 * sshd(8): Fix compilation on systems with IPv6 support in utmpx; bz#2296

 * Allow custom service name for sshd on Cygwin. Permits the use of
   multiple sshd running with different service names.

Checksums:
==========

 - SHA1 (openssh-6.8.tar.gz) = 99903c6ca76e0a2c044711017f81127e12459d37
 - SHA256 (openssh-6.8.tar.gz) = N1uzVarFbrm2CzAwuDu3sRoszmqpK+5phAChP/QNyuw=

 - SHA1 (openssh-6.8p1.tar.gz) = cdbc51e46a902b30d263b05fdc71340920e91c92
 - SHA256 (openssh-6.8p1.tar.gz) = P/ZM5z7hJEgLW/dnuYMNfTwDu8tqvnFrePAZLDfOFg4=

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 djm at mindrot.org  Wed Mar 18 18:18:00 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 18 Mar 2015 18:18:00 +1100 (AEDT)
Subject: [patch] Updated patch for pkcs#11 smartcard readers that have
 a protected PIN path
In-Reply-To: <2AA8AAA7-FD5A-4C22-9EEE-F0D9D08CD6EB@webweaving.org>
References: <2AA8AAA7-FD5A-4C22-9EEE-F0D9D08CD6EB@webweaving.org>
Message-ID: <alpine.BSO.2.11.1503181814000.20131@natsu.mindrot.org>

There is at least one patch in bugzilla for this. I haven't looked at
it because I'm not very experienced with PKCS#11 and lack the hardware,
but you might want to take a look and attach your patch to (one of) the
existing bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2185
https://bugzilla.mindrot.org/show_bug.cgi?id=2240

On Tue, 17 Mar 2015, Dirk-Willem van Gulik wrote:

> Some smartcard readers have keypad to enter the PIN securely (i.e. such that it cannot be intercepted by a rogue (ssh) binary. 
> 
> PKCS#11 allows for enforcing this in hardware. Below patch allows for SSH to make use of this; against head/master as of today.
> 
> Dw.
> 
> 
> commit 7f0250a8ae6c639a19d4e1e24fc112d5e2e1249a
> Author: Dirk-Willem van Gulik <dirkx at webweaving.org>
> Date:   Tue Mar 17 13:41:31 2015 +0100
> 
>     Ensuring support for PINs that can only be entered on a secure keypad (CKF_PROTECTED_AUTHENTICATION_PATH)
> 
> diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
> index c3a112f..b053332 100644
> --- a/ssh-pkcs11.c
> +++ b/ssh-pkcs11.c
> @@ -255,22 +255,30 @@ pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
>  	si = &k11->provider->slotinfo[k11->slotidx];
>  	if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
>  		if (!pkcs11_interactive) {
> -			error("need pin");
> +			error("need pin%s", 
> +				(si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) 
> +					? " entry on reader keypad" : "");
>  			return (-1);
>  		}
> -		snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
> -		    si->token.label);
> -		pin = read_passphrase(prompt, RP_ALLOW_EOF);
> -		if (pin == NULL)
> -			return (-1);	/* bail out */
> +		if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) {
> +			verbose("Deferring PIN entry to keypad of chipcard reader.");
> +			pin = NULL;
> +		} else {
> +			snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
> +				si->token.label);
> +			pin = read_passphrase(prompt, RP_ALLOW_EOF);
> +			if (pin == NULL)
> +				return (-1);    /* bail out */
> +               };
> +
>  		rv = f->C_Login(si->session, CKU_USER,
>  		    (u_char *)pin, pin ? strlen(pin) : 0);
>  		if (rv != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN) {
> -			free(pin);
> +			if (pin) free(pin);
>  			error("C_Login failed: %lu", rv);
>  			return (-1);
>  		}
> -		free(pin);
> +		if (pin) free(pin);
>  		si->logged_in = 1;
>  	}
>  	key_filter[1].pValue = k11->keyid;
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From dirkx at webweaving.org  Wed Mar 18 19:32:15 2015
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Wed, 18 Mar 2015 09:32:15 +0100
Subject: [patch] Updated patch for pkcs#11 smartcard readers that have a
 protected PIN path
In-Reply-To: <alpine.BSO.2.11.1503181814000.20131@natsu.mindrot.org>
References: <2AA8AAA7-FD5A-4C22-9EEE-F0D9D08CD6EB@webweaving.org>
 <alpine.BSO.2.11.1503181814000.20131@natsu.mindrot.org>
Message-ID: <11D5B5D4-CCA1-4B95-9501-065E3779FB40@webweaving.org>

Ok - put a pointer in 2185 which was the most out of date of the two; and updated 2240 with the more recent patch that has the casting right and the newer check on Already Logged in that 2185 missed.

Dw.

> On 18 Mar 2015, at 08:18, Damien Miller <djm at mindrot.org> wrote:
> 
> There is at least one patch in bugzilla for this. I haven't looked at
> it because I'm not very experienced with PKCS#11 and lack the hardware,
> but you might want to take a look and attach your patch to (one of) the
> existing bugs:
> 
> https://bugzilla.mindrot.org/show_bug.cgi?id=2185
> https://bugzilla.mindrot.org/show_bug.cgi?id=2240
> 
> On Tue, 17 Mar 2015, Dirk-Willem van Gulik wrote:
> 
>> Some smartcard readers have keypad to enter the PIN securely (i.e. such that it cannot be intercepted by a rogue (ssh) binary. 
>> 
>> PKCS#11 allows for enforcing this in hardware. Below patch allows for SSH to make use of this; against head/master as of today.
>> 
>> Dw.
>> 
>> 
>> commit 7f0250a8ae6c639a19d4e1e24fc112d5e2e1249a
>> Author: Dirk-Willem van Gulik <dirkx at webweaving.org>
>> Date:   Tue Mar 17 13:41:31 2015 +0100
>> 
>>    Ensuring support for PINs that can only be entered on a secure keypad (CKF_PROTECTED_AUTHENTICATION_PATH)
>> 
>> diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
>> index c3a112f..b053332 100644
>> --- a/ssh-pkcs11.c
>> +++ b/ssh-pkcs11.c
>> @@ -255,22 +255,30 @@ pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
>> 	si = &k11->provider->slotinfo[k11->slotidx];
>> 	if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) {
>> 		if (!pkcs11_interactive) {
>> -			error("need pin");
>> +			error("need pin%s", 
>> +				(si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) 
>> +					? " entry on reader keypad" : "");
>> 			return (-1);
>> 		}
>> -		snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
>> -		    si->token.label);
>> -		pin = read_passphrase(prompt, RP_ALLOW_EOF);
>> -		if (pin == NULL)
>> -			return (-1);	/* bail out */
>> +		if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) {
>> +			verbose("Deferring PIN entry to keypad of chipcard reader.");
>> +			pin = NULL;
>> +		} else {
>> +			snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ",
>> +				si->token.label);
>> +			pin = read_passphrase(prompt, RP_ALLOW_EOF);
>> +			if (pin == NULL)
>> +				return (-1);    /* bail out */
>> +               };
>> +
>> 		rv = f->C_Login(si->session, CKU_USER,
>> 		    (u_char *)pin, pin ? strlen(pin) : 0);
>> 		if (rv != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN) {
>> -			free(pin);
>> +			if (pin) free(pin);
>> 			error("C_Login failed: %lu", rv);
>> 			return (-1);
>> 		}
>> -		free(pin);
>> +		if (pin) free(pin);
>> 		si->logged_in = 1;
>> 	}
>> 	key_filter[1].pValue = k11->keyid;
>> 
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>> 
> 


From list at eworm.de  Wed Mar 18 23:00:08 2015
From: list at eworm.de (Christian Hesse)
Date: Wed, 18 Mar 2015 13:00:08 +0100
Subject: error: mm_request_receive: socket closed
Message-ID: <20150318130008.18dec7b1@leda.localdomain>

Hello everybody,

Just updated to openssh 6.8p1. Everything works just fine, though I get these
lines in syslog on logout:

Mar 18 12:52:05 leda sshd[27487]: Received disconnect from ::1: 11:
disconnected by user
Mar 18 12:52:05 leda sshd[27487]: Disconnected from ::1
Mar 18 12:52:05 leda sshd[27482]: error: mm_request_receive: socket closed

First and second entry is ok, but why does it give an error on socket closed?
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150318/0c849446/attachment-0001.bin>

From mancha1 at zoho.com  Thu Mar 19 00:41:28 2015
From: mancha1 at zoho.com (mancha)
Date: Wed, 18 Mar 2015 13:41:28 +0000
Subject: [patch] updated TCP Wrapper support patch for 6.8p1
Message-ID: <20150318134128.GC12923@zoho.com>

New TCP Wrapper support patch at:

  http://sf.net/projects/mancha/files/misc/openssh-6.8p1-libwrap.diff

Make sure to autoreconf -fiv. Cheers.

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150318/6c5cd404/attachment.bin>

From todor.dimitrov at me.com  Thu Mar 19 01:06:05 2015
From: todor.dimitrov at me.com (Todor Dimitrov)
Date: Wed, 18 Mar 2015 15:06:05 +0100
Subject: OpenSSH Reverse Tunnel / Memory Usage per Connection
Message-ID: <FB0A6168-B9E6-467C-A790-68A9B9AD2B1E@me.com>

Hallo,

we have a scenario where many clients are connected to a server over SSH. Each client sets up a reverse port forward, which is then used to access an HTTP service running on the client. When downloading files through the tunnelled connections, the memory usage per SSH connection on the server continuously increases. The used memory is released only after the connection has been closed by the client. There is a possible correlation between the file size and the number of simultaneous (parallel) downloads, e.g.
* file size 0.5 MB, 50 clients, 500 downloads (30 simultaneous) -> memory usage ~ 2.6 MB per SSH connection on the server
* file size 10 MB, 50 clients, 1000 downloads (60 simultaneous) -> memory usage ~  6.1 MB per SSH connection on the server, where the peak memory usage was at 9.5 MB per server connection, i.e. some of the used memory is freed when the server load decreases.

My question is whether there is a possibility of constraining the amount of memory, which is available to any single connection of the SSH server daemon. Further, why is the memory not freed when no more data is tunnelled through the connection, i.e. when the connection is idle for hours? 

Regards,
Todor Dimitrov

From Anton.Scheffer at amis.nl  Fri Mar 20 06:52:13 2015
From: Anton.Scheffer at amis.nl (Anton Scheffer)
Date: Thu, 19 Mar 2015 19:52:13 +0000
Subject: One SSH_FXP_DATA record split over SSH_MSG_CHANNEL_DATA packets
Message-ID: <F0700D49D73E164A94E8E5FB83C5DE4E1357B79E@AMIS-EX01.AMIS.local>

Hi,

I'm developing my own sftp client.
When I try to read a file larger than 16371 bytes from a OpenSSH server my program fails.
And that is because it doesn't expect a SSH_FXP_DATA record to be send through two SSH_MSG_CHANNEL_DATA packets.

For instance:
  First a SSH_MSG_CHANNEL_DATA packet containing the start of a SSH_FXP_DATA record
    read_packet: done 16393
    read_packet: done 5E0000007B0000400000003FFF67000000FC00003FF60101010101010101....

  And then a SSH_MSG_CHANNEL_DATA packet containing the last part the SSH_FXP_DATA record
    read_packet: done 12
    read_packet: done 5E0000007B00000003AA1133

Is this normal, to be expected, behavior? I can't find anything regarding this in the RFC's.

I see this on OpenSSH_6.4 and OpenSSH_4.3 using these settings
aes128-cbc
aes128-cbc
hmac-sha1
hmac-sha1
none
none

Anton



From djm at mindrot.org  Fri Mar 20 08:39:06 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 20 Mar 2015 08:39:06 +1100 (AEDT)
Subject: One SSH_FXP_DATA record split over SSH_MSG_CHANNEL_DATA
 packets
In-Reply-To: <F0700D49D73E164A94E8E5FB83C5DE4E1357B79E@AMIS-EX01.AMIS.local>
References: <F0700D49D73E164A94E8E5FB83C5DE4E1357B79E@AMIS-EX01.AMIS.local>
Message-ID: <alpine.BSO.2.11.1503200835190.20131@natsu.mindrot.org>

On Thu, 19 Mar 2015, Anton Scheffer wrote:

> Hi,
> 
> I'm developing my own sftp client.
>
> When I try to read a file larger than 16371 bytes from a OpenSSH
> server my program fails. And that is because it doesn't expect a
> SSH_FXP_DATA record to be send through two SSH_MSG_CHANNEL_DATA
> packets.
...
> Is this normal, to be expected, behavior? I can't find anything
> regarding this in the RFC's.

Yes, the filexfer runs atop the channel protocol and is completely
ignorant of the latter's framing of its messages. In OpenSSH, they
are totally separate programs.

-d

From list at eworm.de  Fri Mar 20 08:38:37 2015
From: list at eworm.de (Christian Hesse)
Date: Thu, 19 Mar 2015 22:38:37 +0100
Subject: [PATCH 1/1] monitor_wrap: do not give error but debug message
In-Reply-To: <20150318130008.18dec7b1@leda.localdomain>
References: <20150318130008.18dec7b1@leda.localdomain>
Message-ID: <1426801117-17639-1-git-send-email-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Commit 72ef7c14 (support --without-openssl at configure time) added an
error message in mm_request_receive() when socket is closed. Make this a
debug message.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 monitor_wrap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/monitor_wrap.c b/monitor_wrap.c
index b379f05..f13894a 100644
--- a/monitor_wrap.c
+++ b/monitor_wrap.c
@@ -154,7 +154,7 @@ mm_request_receive(int sock, Buffer *m)
 
 	if (atomicio(read, sock, buf, sizeof(buf)) != sizeof(buf)) {
 		if (errno == EPIPE) {
-			error("%s: socket closed", __func__);
+			debug("%s: socket closed", __func__);
 			cleanup_exit(255);
 		}
 		fatal("%s: read: %s", __func__, strerror(errno));
-- 
2.3.3


From djm at mindrot.org  Fri Mar 20 08:51:49 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 20 Mar 2015 08:51:49 +1100 (AEDT)
Subject: [PATCH 1/1] monitor_wrap: do not give error but debug message
In-Reply-To: <1426801117-17639-1-git-send-email-list@eworm.de>
References: <20150318130008.18dec7b1@leda.localdomain>
 <1426801117-17639-1-git-send-email-list@eworm.de>
Message-ID: <alpine.BSO.2.11.1503200850540.20131@natsu.mindrot.org>

On Thu, 19 Mar 2015, Christian Hesse wrote:

> From: Christian Hesse <mail at eworm.de>
> 
> Commit 72ef7c14 (support --without-openssl at configure time) added an
> error message in mm_request_receive() when socket is closed. Make this a
> debug message.
> 
> Signed-off-by: Christian Hesse <mail at eworm.de>
> ---
>  monitor_wrap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/monitor_wrap.c b/monitor_wrap.c
> index b379f05..f13894a 100644
> --- a/monitor_wrap.c
> +++ b/monitor_wrap.c
> @@ -154,7 +154,7 @@ mm_request_receive(int sock, Buffer *m)
>  
>  	if (atomicio(read, sock, buf, sizeof(buf)) != sizeof(buf)) {
>  		if (errno == EPIPE) {
> -			error("%s: socket closed", __func__);
> +			debug("%s: socket closed", __func__);

Actually, I think it was a debugging change that I accidentally committed
somewhere between 6.7 and 6.8. It can be deleted entirely.

-d

From list at eworm.de  Fri Mar 20 09:02:35 2015
From: list at eworm.de (Christian Hesse)
Date: Thu, 19 Mar 2015 23:02:35 +0100
Subject: [PATCH 1/1] monitor_wrap: do not give error message on socket closed
In-Reply-To: <alpine.BSO.2.11.1503200850540.20131@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503200850540.20131@natsu.mindrot.org>
Message-ID: <1426802555-21311-1-git-send-email-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Commit 72ef7c14 (support --without-openssl at configure time) added an
error message in mm_request_receive() when socket is closed. Remove it.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 monitor_wrap.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/monitor_wrap.c b/monitor_wrap.c
index b379f05..d39d491 100644
--- a/monitor_wrap.c
+++ b/monitor_wrap.c
@@ -153,10 +153,8 @@ mm_request_receive(int sock, Buffer *m)
 	debug3("%s entering", __func__);
 
 	if (atomicio(read, sock, buf, sizeof(buf)) != sizeof(buf)) {
-		if (errno == EPIPE) {
-			error("%s: socket closed", __func__);
+		if (errno == EPIPE)
 			cleanup_exit(255);
-		}
 		fatal("%s: read: %s", __func__, strerror(errno));
 	}
 	msg_len = get_u32(buf);
-- 
2.3.3


From djm at mindrot.org  Fri Mar 20 09:33:25 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 20 Mar 2015 09:33:25 +1100 (AEDT)
Subject: [PATCH 1/1] monitor_wrap: do not give error message on socket
 closed
In-Reply-To: <1426802555-21311-1-git-send-email-list@eworm.de>
References: <alpine.BSO.2.11.1503200850540.20131@natsu.mindrot.org>
 <1426802555-21311-1-git-send-email-list@eworm.de>
Message-ID: <alpine.BSO.2.11.1503200932520.20131@natsu.mindrot.org>

On Thu, 19 Mar 2015, Christian Hesse wrote:

> From: Christian Hesse <mail at eworm.de>
> 
> Commit 72ef7c14 (support --without-openssl at configure time) added an
> error message in mm_request_receive() when socket is closed. Remove it.

I committed something identical already, both on master and on the
V_6_8 branch.

-d

From debian at jstimpfle.de  Sun Mar 22 08:48:10 2015
From: debian at jstimpfle.de (Jens Stimpfle)
Date: Sat, 21 Mar 2015 22:48:10 +0100
Subject: issues with forced pty allocation
Message-ID: <20150321214810.GB659@jstimpfle.de>

Hi,

I noticed that ssh will hang if stdin is not a tty and I force pty
allocation:

client:~$ echo echo a | ssh -tt server
server:~$ echo a
a
server:~$

In the above session, I only typed the first line. At this point, the
session hangs (until I ctrl-C). I expected to be returned to my local
shell.

On the server side, the shell is still running. strace shows it is
blocked while reading from stdin. That would mean sshd didn't close the
writing end of the master side of the pty. I also noticed that at this
point the sshd process handling my session has one fd less than it has
in a normal interactive session.

I did some more debugging but I'm not sure what results may be relevant.

Would you consider this a bug at all? I think it is one but I might
misunderstand something...

Regards,
Jens Stimpfle

From matthew at debian.org  Wed Mar 25 05:28:52 2015
From: matthew at debian.org (Matthew Vernon)
Date: Tue, 24 Mar 2015 18:28:52 +0000
Subject: [Debian bug 781107] ssh-keygen -F return code has changed and is
 not documented
Message-ID: <5511ACE4.2040400@debian.org>

Hi,

I tripped over the effects of commit 660854 [0] when moving some
infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible
module used "return 0, but no output" for 'host not found in known_hosts
file', and now complains that ssh-keygen is returning an error status. I
don't think this change in API was announced in the release notes?

i.e. ssh-keygen -F foo.invalid -f ~/.ssh/known_hosts used to return 0
(and no output), and now returns 1 (and no output).

Is the non-zero return code really helpful here? Much infrastructure
will have to support the old API for the foreseeable future, and I'm not
sure it's really an error condition for a host to not be in the
known_hosts file.

Less controversially, could the return values of ssh-keygen and their
meanings be documented (and flagged when they change), please?

Regards,

Matthew

[0]
https://anongit.mindrot.org/openssh.git/commit/?id=660854859cad31d234edb9353fb7ca2780df8128

From djm at mindrot.org  Wed Mar 25 09:53:54 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 09:53:54 +1100 (AEDT)
Subject: [Debian bug 781107] ssh-keygen -F return code has changed and
 is not documented
In-Reply-To: <5511ACE4.2040400@debian.org>
References: <5511ACE4.2040400@debian.org>
Message-ID: <alpine.BSO.2.11.1503250952390.21104@natsu.mindrot.org>

On Tue, 24 Mar 2015, Matthew Vernon wrote:

> Hi,
> 
> I tripped over the effects of commit 660854 [0] when moving some
> infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible
> module used "return 0, but no output" for 'host not found in known_hosts
> file', and now complains that ssh-keygen is returning an error status. I
> don't think this change in API was announced in the release notes?
> 
> i.e. ssh-keygen -F foo.invalid -f ~/.ssh/known_hosts used to return 0
> (and no output), and now returns 1 (and no output).
> 
> Is the non-zero return code really helpful here?

Yes, it lets you tell whether the hostname is present in known_hosts.

> Less controversially, could the return values of ssh-keygen and their
> meanings be documented (and flagged when they change), please?

Sure, someone has to do the work though.

-d

From djm at mindrot.org  Wed Mar 25 10:26:22 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 10:26:22 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
Message-ID: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>

Hi,

OpenSSH git master now disabled SSH protocol 1 at compile time by
default. If you want it back, then you'll need to pass --with-ssh1
to configure before you build.

We expect to ship this configuration for openssh-6.9 in a few
months.

-d

From dan at doxpara.com  Wed Mar 25 12:06:28 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 24 Mar 2015 18:06:28 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
Message-ID: <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>

Hmm.  Feels a little aggressive for ssh client.  Support heartily for sshd.

--Dan

On Tue, Mar 24, 2015 at 4:26 PM, Damien Miller <djm at mindrot.org> wrote:

> Hi,
>
> OpenSSH git master now disabled SSH protocol 1 at compile time by
> default. If you want it back, then you'll need to pass --with-ssh1
> to configure before you build.
>
> We expect to ship this configuration for openssh-6.9 in a few
> months.
>
> -d
> _______________________________________________
> 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  Wed Mar 25 12:31:42 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 12:31:42 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>

On Tue, 24 Mar 2015, Dan Kaminsky wrote:

> Hmm.  Feels a little aggressive for ssh client.  Support heartily for sshd.

People who need it can build their own, or OS vendors might supply a
non-default v.1 capable client binary themselves.

IMO it's time to apply some selection pressure to a protocol that can't
be secured.

-d

From dan at doxpara.com  Wed Mar 25 13:37:44 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 24 Mar 2015 19:37:44 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
Message-ID: <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>

On Tuesday, March 24, 2015, Damien Miller <djm at mindrot.org> wrote:

> On Tue, 24 Mar 2015, Dan Kaminsky wrote:
>
> > Hmm.  Feels a little aggressive for ssh client.  Support heartily for
> sshd.
>
> People who need it can build their own, or OS vendors might supply a
> non-default v.1 capable client binary themselves.
>
> IMO it's time to apply some selection pressure to a protocol that can't
> be secured.
>
> -d
>

I'm getting some numbers, standby

From nkadel at gmail.com  Wed Mar 25 14:00:22 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Tue, 24 Mar 2015 23:00:22 -0400
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
Message-ID: <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>

On Tue, Mar 24, 2015 at 10:37 PM, Dan Kaminsky <dan at doxpara.com> wrote:
> On Tuesday, March 24, 2015, Damien Miller <djm at mindrot.org> wrote:
>
>> On Tue, 24 Mar 2015, Dan Kaminsky wrote:
>>
>> > Hmm.  Feels a little aggressive for ssh client.  Support heartily for
>> sshd.
>>
>> People who need it can build their own, or OS vendors might supply a
>> non-default v.1 capable client binary themselves.
>>
>> IMO it's time to apply some selection pressure to a protocol that can't
>> be secured.
>>
>> -d
>>
>
> I'm getting some numbers, standby

If it's disabled by default in any major distributions, it's going to
break a lot of git repositories, svn+ssh repositories, and rsync
environments. Can it wait until version 7, instead of being slipped
into a minor update?

From calestyo at scientia.net  Wed Mar 25 14:15:42 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Wed, 25 Mar 2015 04:15:42 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
Message-ID: <1427253342.10191.405.camel@scientia.net>

On Wed, 2015-03-25 at 10:26 +1100, Damien Miller wrote: 
> OpenSSH git master now disabled SSH protocol 1 at compile time by
> default. If you want it back, then you'll need to pass --with-ssh1
> to configure before you build.
+1

- People who use SSH are expected to want security (which v1 doesn't
provide) - people wo actually don't want security, shouldn't have used
SSH in the first place, but could have used rsh, telnet, etc.

- Many distros shipped it anyway with v1 disabled.

- It's not removed from the code but just disabled at compile time, if
people really think they'd desperately need it, they can compile on
their own.


Good move!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/a71bd5df/attachment.bin>

From calestyo at scientia.net  Wed Mar 25 14:17:01 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Wed, 25 Mar 2015 04:17:01 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
Message-ID: <1427253421.10191.407.camel@scientia.net>

On Tue, 2015-03-24 at 23:00 -0400, Nico Kadel-Garcia wrote: 
> If it's disabled by default in any major distributions
isn't that already the case?

> , it's going to
> break a lot of git repositories, svn+ssh repositories, and rsync
> environments.
Does any of this use ssh1 specific features which cannot be done with v2
or where a switch isn't as simple as reconfiguring the server?
Actually things like gitolite work ONLY with v2.

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/7009d84f/attachment.bin>

From djm at mindrot.org  Wed Mar 25 15:16:21 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 15:16:21 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>

On Tue, 24 Mar 2015, Nico Kadel-Garcia wrote:

> If it's disabled by default in any major distributions, it's going
> to break a lot of git repositories, svn+ssh repositories, and rsync
> environments.

The chronology doesn't support this.

When Subversion 1.0 was released in 2004, OpenSSH had been defaulting to
protocol v.2 for almost three years.

git was first released two years later, at which time v.2 had been the
default for over five years.

Seriously, protocol 2 became the default in *2001* and the old protocol
has been disabled for new sshd installs for the last eight years. If
anything, we've moved way too slowly.

> Can it wait until version 7, instead of being slipped into a minor
> update?

Our version number has been a simple counter for years; the first digit
of the version has no significance beyond that.

Distributions will make their own decisions about what to support and
they already ship far more intrusive changes than flipping a configure
switch. I hope they ship a "openssh-ssh1" package instead of just
setting it back through.

-d

From dan at doxpara.com  Wed Mar 25 16:05:03 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 24 Mar 2015 22:05:03 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
Message-ID: <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>

Alright, so I pulled the data from scans.io,  There's actually 82,650
devices on the open Internet claiming support for <=SSH-1.5, generally
routers.  Top 20 on that is:

$ head -n 20 ssh1_versions.txt
  39148 SSH-1.5-Cisco-1.25
  14477 SSH-1.5-HUAWEI-VRP3.1
  10571 SSH-1.5-1.0.0
   4634 SSH-1.5-HUAWEI-VRP-3.10
   3284 SSH-1.5-1.2.33
   2965 SSH-1.5-VRP-3.3
   1836 SSH-1.5-VRP-3.4
   1125 SSH-1.5-Server
   1034 SSH-1.5-X
   1022 SSH-1.5-1.2.22j4rad
    753 SSH-1.5-1.2.26
    538 SSH-1.5-OpenSSH_4.4
    422 SSH-1.5-SSH
    379 SSH-1.5-HUAWEI-VRP5.0
    304 SSH-1.5-OpenSSH_2.3.0_Mikrotik_v2.9
    270 SSH-1.5-SSHServer
    269 SSH-1.5-1.2.27
    223 SSH-1.5-OpenSSH_3.7.1p2
    175 SSH-1.5-Huawei
    136 SSH-1.5-LtSSH_3.6

Of course, this is out of a total of 15,124,618 SSH servers, granting a
compat rate greater than 99.99%.  However, distinctly and painfully unlike
SSL/TLS, SSH is successfully deployed and used on internal networks that
cannot be scanned from the open Internet.  It's also a protocol of fairly
critical importance, uniquely used in a "hop by hop" manner in which each
hop actually has to work.

7.3% of Cisco routers on the open Internet only support SSHv1.  The numbers
inside private networks are likely to be higher.

I can see the argument for pushing people to upgrade, but not by surprise
in a minor version.  If SSH is going to block old insecure versions it has
a much bigger problem, because upgrade rates on SSH on the Internet are
actually not fantastic.  Here's the top 40 across all versions of SSH:

$ head -n 40 sshall_versions.txt
2412684 SSH-2.0-OpenSSH_5.3
 984056 SSH-2.0-OpenSSH_4.3
 936855 SSH-2.0-dropbear_0.51
 854624 SSH-2.0-dropbear_0.46
 798414 SSH-2.0-OpenSSH_6.0p1
 790303 SSH-2.0-OpenSSH_6.6.1p1
 771396 SSH-2.0-OpenSSH_5.9p1
 465647 SSH-2.0-OpenSSH_5.5p1
 430372 SSH-2.0-ROSSSH
 338577 SSH-1.99-Cisco-1.25
 337282 SSH-2.0-OpenSSH_6.2
 325681 SSH-2.0-dropbear_0.52
 315864 SSH-2.0-dropbear_2012.55
 305623 SSH-2.0-dropbear_2013.58
 178282 SSH-2.0-OpenSSH
 169613 SSH-2.0-OpenSSH_4.7
 162892 SSH-2.0-OpenSSH_5.1p1
 160225 SSH-2.0-OpenSSH_5.3p1
 150068 SSH-2.0-Cisco-1.25
 141795 SSH-2.0-OpenSSH_5.1
 130653 SSH-2.0-OpenSSH_6.7
 122612 SSH-2.0-RomSShell_4.31
 121542 SSH-2.0-homepl
 116630 SSH-2.0-OpenSSH_5.8
 112202 SSH-2.0-OpenSSH_6.4
  98829 SSH-2.0-dropbear_2011.54
  96457 SSH-2.0-OpenSSH_4.3-HipServ
  88471 SSH-2.0-OpenSSH_5.2
  88444 SSH-2.0-OpenSSH_5.9
  86001 SSH-2.0-dropbear_0.48
  69497 SSH-2.0-OpenSSH_5.4p1
  67565 SSH-1.99-DOPRA-1.5
  60749 SSH-2.0-OpenSSH_6.1
  59323 SSH-2.0-ARRIS_0.50
  59103 SSH-2.0-lancom
  58497 SSH-2.0-Trendchip_0.1
  57757 SSH-2.0-OpenSSH_5.6
  55951 SSH-2.0-OpenSSH_6.2p2
  54750 SSH-2.0-dropbear_0.50
  52685 SSH-2.0-OpenSSH_6.6p2-hpn14v4

This is specifically a scenario where OpenSSH should measure twice and cut
once.  The worst case scenario is that people update even less than they
already do, because who knows what servers are no longer important enough
to require connectivity to next.  Start the discussion, absolutely, but
let's not forget even SSHv1 is miles better than Telnet, and this just
isn't the rapidly updating consumer browser ecosystem we're messing with
here.

--Dan




On Tue, Mar 24, 2015 at 9:16 PM, Damien Miller <djm at mindrot.org> wrote:

> On Tue, 24 Mar 2015, Nico Kadel-Garcia wrote:
>
> > If it's disabled by default in any major distributions, it's going
> > to break a lot of git repositories, svn+ssh repositories, and rsync
> > environments.
>
> The chronology doesn't support this.
>
> When Subversion 1.0 was released in 2004, OpenSSH had been defaulting to
> protocol v.2 for almost three years.
>
> git was first released two years later, at which time v.2 had been the
> default for over five years.
>
> Seriously, protocol 2 became the default in *2001* and the old protocol
> has been disabled for new sshd installs for the last eight years. If
> anything, we've moved way too slowly.
>
> > Can it wait until version 7, instead of being slipped into a minor
> > update?
>
> Our version number has been a simple counter for years; the first digit
> of the version has no significance beyond that.
>
> Distributions will make their own decisions about what to support and
> they already ship far more intrusive changes than flipping a configure
> switch. I hope they ship a "openssh-ssh1" package instead of just
> setting it back through.
>
> -d
>

From djm at mindrot.org  Wed Mar 25 17:10:36 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 17:10:36 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>



On Tue, 24 Mar 2015, Dan Kaminsky wrote:

> Alright, so I pulled the data from scans.io,  There's actually 82,650
> devices on the open Internet claiming support for <=SSH-1.5, generally
> routers.  Top 20 on that is:
[snip]

> Of course, this is out of a total of 15,124,618 SSH servers, granting a
> compat rate greater than 99.99%.

OK, so most of the <0.01% of users are network administrators - a
fairly technical audience and one that I doubt would have trouble
procuring a v.1 capable ssh client. I bet the majority of admins
wouldn't even be using OpenSSH as the client.

> However, distinctly and painfully unlike
> SSL/TLS, SSH is successfully deployed and used on internal networks that
> cannot be scanned from the open Internet.  It's also a protocol of fairly
> critical importance, uniquely used in a "hop by hop" manner in which each
> hop actually has to work.

Not really, people can port-forward. Besides, the most common hop-by-hop
configuration is the gateway bastion, which also happens to be the 1)
the most important to keep up to date and 2) the easiest to fix (since
you only need to fix the bastion).

> 7.3% of Cisco routers on the open Internet only support SSHv1.  The numbers
> inside private networks are likely to be higher.
> 
> I can see the argument for pushing people to upgrade, but not by surprise in
> a minor version.  If SSH is going to block old insecure versions it has a
> much bigger problem, because upgrade rates on SSH on the Internet are
> actually not fantastic.  Here's the top 40 across all versions of SSH:
> 
> $ head -n 40 sshall_versions.txt
> 2412684 SSH-2.0-OpenSSH_5.3
>  984056 SSH-2.0-OpenSSH_4.3
>  936855 SSH-2.0-dropbear_0.51
>  854624 SSH-2.0-dropbear_0.46
>  798414 SSH-2.0-OpenSSH_6.0p1
[snip]

This brings to light another point: we can turn off v.1 by default at
our end, but it won't filter through to what the majority of users see
for several years.

> This is specifically a scenario where OpenSSH should measure twice and cut
> once.  The worst case scenario is that people update even less than they
> already do, because who knows what servers are no longer important enough to
> require connectivity to next.

> Start the discussion, absolutely

We started the discussion _14 years ago_ by making protocol 2 the default.

We prodded people _8 years ago_ by making protocol 2 the only thing
supported on the server for new installs.

We prodded people again _6 years ago_ by requiring explicit configuration
at both client and server to enable v.1 at all.

At this point, I don't think any further discussion is going to make any
difference. Do you think another two years would make an appreciable
change to the numbers you posted above, beyond old hardware literally
dying of old age?

-d

From dan at doxpara.com  Wed Mar 25 17:25:26 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 24 Mar 2015 23:25:26 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
Message-ID: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>

There's a world of difference between changing defaults and killing
functionality.  SSH in general and OpenSSH in particular is part of what
we'll eventually get around to identifying as (I know everyone hates this
word) critical infrastructure.  That means it doesn't break, particularly
not intentionally, and even more particularly not without time, warning,
and probably public input.

There's a universe of assumptions going on here, like that most people
managing these clients are network administrators *or even human beings* as
opposed to automated update processes.  Or that others have the same
ridiculous superpowers for figuring things out like port forwarding chains
as opposed to just SSH'ing over and over.  Gateway bastions are often
chained, and if any of those gets updated, suddenly routers can't be
configured.  Not all boxes are of equal importance.

The risk here is that people suppress updating OpenSSH even more than they
have.  Don't give them a good reason.  Aggressively breaking changes don't
belong in minor versions in code of this criticality.

Now threatening the breaking change, even possibly attaching a date to it,
that creates the sort of pressure that actually does get servers upgraded.

Two questions:

1) What is the worst known SSHv1 attack right now?
2) What is the oldest build of OpenSSH you believe is safe to operate, as a
client, and as a server?  Imagine there was a compliance bar -- where would
you put it?

I'm no fan of SSHv1, to be clear.  This is exclusively process pushback.


On Tue, Mar 24, 2015 at 11:10 PM, Damien Miller <djm at mindrot.org> wrote:

>
>
> On Tue, 24 Mar 2015, Dan Kaminsky wrote:
>
> > Alright, so I pulled the data from scans.io,  There's actually 82,650
> > devices on the open Internet claiming support for <=SSH-1.5, generally
> > routers.  Top 20 on that is:
> [snip]
>
> > Of course, this is out of a total of 15,124,618 SSH servers, granting a
> > compat rate greater than 99.99%.
>
> OK, so most of the <0.01% of users are network administrators - a
> fairly technical audience and one that I doubt would have trouble
> procuring a v.1 capable ssh client. I bet the majority of admins
> wouldn't even be using OpenSSH as the client.
>
> > However, distinctly and painfully unlike
> > SSL/TLS, SSH is successfully deployed and used on internal networks that
> > cannot be scanned from the open Internet.  It's also a protocol of fairly
> > critical importance, uniquely used in a "hop by hop" manner in which each
> > hop actually has to work.
>
> Not really, people can port-forward. Besides, the most common hop-by-hop
> configuration is the gateway bastion, which also happens to be the 1)
> the most important to keep up to date and 2) the easiest to fix (since
> you only need to fix the bastion).
>
> > 7.3% of Cisco routers on the open Internet only support SSHv1.  The
> numbers
> > inside private networks are likely to be higher.
> >
> > I can see the argument for pushing people to upgrade, but not by
> surprise in
> > a minor version.  If SSH is going to block old insecure versions it has a
> > much bigger problem, because upgrade rates on SSH on the Internet are
> > actually not fantastic.  Here's the top 40 across all versions of SSH:
> >
> > $ head -n 40 sshall_versions.txt
> > 2412684 SSH-2.0-OpenSSH_5.3
> >  984056 SSH-2.0-OpenSSH_4.3
> >  936855 SSH-2.0-dropbear_0.51
> >  854624 SSH-2.0-dropbear_0.46
> >  798414 SSH-2.0-OpenSSH_6.0p1
> [snip]
>
> This brings to light another point: we can turn off v.1 by default at
> our end, but it won't filter through to what the majority of users see
> for several years.
>
> > This is specifically a scenario where OpenSSH should measure twice and
> cut
> > once.  The worst case scenario is that people update even less than they
> > already do, because who knows what servers are no longer important
> enough to
> > require connectivity to next.
>
> > Start the discussion, absolutely
>
> We started the discussion _14 years ago_ by making protocol 2 the default.
>
> We prodded people _8 years ago_ by making protocol 2 the only thing
> supported on the server for new installs.
>
> We prodded people again _6 years ago_ by requiring explicit configuration
> at both client and server to enable v.1 at all.
>
> At this point, I don't think any further discussion is going to make any
> difference. Do you think another two years would make an appreciable
> change to the numbers you posted above, beyond old hardware literally
> dying of old age?
>
> -d
>

From djm at mindrot.org  Wed Mar 25 18:23:15 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 18:23:15 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503251731440.21104@natsu.mindrot.org>

On Tue, 24 Mar 2015, Dan Kaminsky wrote:

> The risk here is that people suppress updating OpenSSH even more than they
> have.  Don't give them a good reason.  Aggressively breaking changes don't
> belong in minor versions in code of this criticality.

There are no minor releases, there are no major releases - there is only
a decimal version number that increments by 0.1 per release.

> Now threatening the breaking change, even possibly attaching a date to it,
> that creates the sort of pressure that actually does get servers upgraded.

That's effectively what we're doing. Approximately 0% of the
administrators of ancient Cisco devices will compile OpenSSH themselves
and even fewer read our release notes, so us turning off v.1 support is
the best way to publicise a change that is long overdue.

So please, go and tell the world how terrible we are and make as much
noise as possible :)

The source releases we make sit at the beginning of a very slow upgrade
pipe - your own numbers demonstrate that clearly. Ubuntu don't have
an LTS scheduled this year and Redhat (probably the worst offender at
keeping ancient OpenSSH on the Internet) haven't even announced their
next RHEL.

> Two questions:
> 
> 1) What is the worst known SSHv1 attack right now?

It's hard to say, is the use of CRC32 as a MAC worse than the baked in
use of MD5 for signatures? Both seem a bit worse than the lack of proper
PFS and the terribly weak private key format, and much worse than the
lousy cipher choice.

Basically, I wouldn't be surprised if the "some capability" against SSH
mentioned in the Bullrun documents was an ability to break v.1, at least
via active MITM.

> 2) What is the oldest build of OpenSSH you believe is safe to operate, as a
> client, and as a server?  Imagine there was a compliance bar -- where would
> you put it?

Personally, I wouldn't choose to run anything at the server that isn't
pre-auth sandboxed so >=5.9 (released 2011/09), but I'm pretty paranoid.

At the other extreme, someone (not me) could make the case that anything
with AES-CTR and DH-GEX can be configured for reasonably safe crypto
if you're willing to aggressively patch out the security bugs like the
really-long term support OS distributions do. So that's basically
anything back to 2005.

Basically, anything that I think is remotely sensible to run is capable
of protocol v.2 and uses it by default.

-d

From djm at mindrot.org  Wed Mar 25 18:48:41 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 18:48:41 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>

On Tue, 24 Mar 2015, Dan Kaminsky wrote:

BTW you didn't respond to this. IMO it is the essence of the problem:

> > At this point, I don't think any further discussion is going to
> > make any difference. Do you think another two years would make an
> > appreciable change to the numbers you posted above, beyond old
> > hardware literally dying of old age?

Our ability to influence people who run truly obsolete software is
extremely limited. The best we can do is deprecate as noisily as
possible after extremely generous grace period. This is what we are
doing

-d

From dan at doxpara.com  Wed Mar 25 18:54:04 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 25 Mar 2015 00:54:04 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
Message-ID: <CAEW7AC=Ym_ndXuz=GSztB_WtA0WHrvb45eF2zOK11P7OVc=4=w@mail.gmail.com>

Protocols and ciphers are sunsetted all the time, this is a regular thing,
but there are announcements before breaking changes are inserted.  You
assume people are slow to update anyway; some are, some aren't, what you're
doing is wildly rewarding the slow updaters and punishing the fast ones.
That has negative effects elsewhere.

What would it hurt to announce the release in 3-6 months will drop SSHv1 to
a compile time option, and that people should be running (for example) at
least OpenSSH 5.9x?  You've got vendor class authority here, tell people
what you want and give them some time to implement your directive.  The
alternative is they eventually trace back why some random critical system
failed to this very thread and are like, yeah, never blindly push *that*
guy's code...


On Wed, Mar 25, 2015 at 12:48 AM, Damien Miller <djm at mindrot.org> wrote:

> On Tue, 24 Mar 2015, Dan Kaminsky wrote:
>
> BTW you didn't respond to this. IMO it is the essence of the problem:
>
> > > At this point, I don't think any further discussion is going to
> > > make any difference. Do you think another two years would make an
> > > appreciable change to the numbers you posted above, beyond old
> > > hardware literally dying of old age?
>
> Our ability to influence people who run truly obsolete software is
> extremely limited. The best we can do is deprecate as noisily as
> possible after extremely generous grace period. This is what we are
> doing
>
> -d
>

From dan at doxpara.com  Wed Mar 25 19:03:26 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 25 Mar 2015 01:03:26 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=Ym_ndXuz=GSztB_WtA0WHrvb45eF2zOK11P7OVc=4=w@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <CAEW7AC=Ym_ndXuz=GSztB_WtA0WHrvb45eF2zOK11P7OVc=4=w@mail.gmail.com>
Message-ID: <CAEW7ACmq-9Hf3ecuWa78gq-ULTO2yzqN05K7oM7m8dpLK474gQ@mail.gmail.com>

(Also, assume the sandbox doesn't exist when you decide what build people
should upgrade to.)

On Wed, Mar 25, 2015 at 12:54 AM, Dan Kaminsky <dan at doxpara.com> wrote:

> Protocols and ciphers are sunsetted all the time, this is a regular thing,
> but there are announcements before breaking changes are inserted.  You
> assume people are slow to update anyway; some are, some aren't, what you're
> doing is wildly rewarding the slow updaters and punishing the fast ones.
> That has negative effects elsewhere.
>
> What would it hurt to announce the release in 3-6 months will drop SSHv1
> to a compile time option, and that people should be running (for example)
> at least OpenSSH 5.9x?  You've got vendor class authority here, tell people
> what you want and give them some time to implement your directive.  The
> alternative is they eventually trace back why some random critical system
> failed to this very thread and are like, yeah, never blindly push *that*
> guy's code...
>
>
> On Wed, Mar 25, 2015 at 12:48 AM, Damien Miller <djm at mindrot.org> wrote:
>
>> On Tue, 24 Mar 2015, Dan Kaminsky wrote:
>>
>> BTW you didn't respond to this. IMO it is the essence of the problem:
>>
>> > > At this point, I don't think any further discussion is going to
>> > > make any difference. Do you think another two years would make an
>> > > appreciable change to the numbers you posted above, beyond old
>> > > hardware literally dying of old age?
>>
>> Our ability to influence people who run truly obsolete software is
>> extremely limited. The best we can do is deprecate as noisily as
>> possible after extremely generous grace period. This is what we are
>> doing
>>
>> -d
>>
>
>

From djm at mindrot.org  Wed Mar 25 19:10:53 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 19:10:53 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=Ym_ndXuz=GSztB_WtA0WHrvb45eF2zOK11P7OVc=4=w@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <CAEW7AC=Ym_ndXuz=GSztB_WtA0WHrvb45eF2zOK11P7OVc=4=w@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503251909430.21104@natsu.mindrot.org>

On Wed, 25 Mar 2015, Dan Kaminsky wrote:

> What would it hurt to announce the release in 3-6 months will drop
> SSHv1 to a compile time option

We did exactly that in the last release. See what I mean about nobody
reading the release notes?

> The alternative is they eventually trace back why some random critical
> system failed to this very thread and are like, yeah, never blindly
> push *that* guy's code...

I hope nobody ever blindly pushes my code.

-d


From dan at doxpara.com  Wed Mar 25 19:17:30 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 25 Mar 2015 01:17:30 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251909430.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <CAEW7AC=Ym_ndXuz=GSztB_WtA0WHrvb45eF2zOK11P7OVc=4=w@mail.gmail.com>
 <alpine.BSO.2.11.1503251909430.21104@natsu.mindrot.org>
Message-ID: <CAEW7ACnuEiXG2bohTGeoJv9EP_cuX15m23-oPMuCbG62N=2jgg@mail.gmail.com>

We can be a little louder than release notes. It's probably a little
sketchy to just warn people against 5.x with all the backporting of
security fixes going on.  It'd be nice to say the specific CVE's or
patchsets you'd like people to be sure they're running.  As you say,
there's some nasty capability out there.

And after all these years, there's a lot of trust in you, and OpenSSH.
It's well earned.

It's a good time to be doing this shift.  A lot of crypto is being
sunsetted.  Just recommending a bit more awareness first.


On Wed, Mar 25, 2015 at 1:10 AM, Damien Miller <djm at mindrot.org> wrote:

> On Wed, 25 Mar 2015, Dan Kaminsky wrote:
>
> > What would it hurt to announce the release in 3-6 months will drop
> > SSHv1 to a compile time option
>
> We did exactly that in the last release. See what I mean about nobody
> reading the release notes?
>
> > The alternative is they eventually trace back why some random critical
> > system failed to this very thread and are like, yeah, never blindly
> > push *that* guy's code...
>
> I hope nobody ever blindly pushes my code.
>
> -d
>
>

From gert at greenie.muc.de  Wed Mar 25 19:45:00 2015
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 25 Mar 2015 09:45:00 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
Message-ID: <20150325084500.GQ21893@greenie.muc.de>

Hi,

On Wed, Mar 25, 2015 at 10:26:22AM +1100, Damien Miller wrote:
> OpenSSH git master now disabled SSH protocol 1 at compile time by
> default. If you want it back, then you'll need to pass --with-ssh1
> to configure before you build.

I applaud the decision to remove ssh v1 (by default) from the sshd side
of things.  OTOH, I have to deal with lots of stupid and old devices that 
do not offer SSH v2 (Routers, Switches, that sort of stuff), so having v1 
in the *client* (only!) is something I would miss...

SSHv1 might not be great, but it's better than (unencrypted) telnet.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From plautrba at redhat.com  Wed Mar 25 21:14:53 2015
From: plautrba at redhat.com (Petr Lautrbach)
Date: Wed, 25 Mar 2015 11:14:53 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251731440.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251731440.21104@natsu.mindrot.org>
Message-ID: <55128A9D.3020507@redhat.com>

On 03/25/2015 08:23 AM, Damien Miller wrote:

> The source releases we make sit at the beginning of a very slow upgrade
> pipe - your own numbers demonstrate that clearly. Ubuntu don't have
> an LTS scheduled this year and Redhat (probably the worst offender at
> keeping ancient OpenSSH on the Internet) haven't even announced their
> next RHEL.
> 

The Red Hat Enterprise Linux 7.1 with openssh-6.6.1p1 was released March
5, 2015.


Petr
-- 
Petr Lautrbach


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/a574582d/attachment.bin>

From djm at mindrot.org  Wed Mar 25 21:51:26 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 25 Mar 2015 21:51:26 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <55128A9D.3020507@redhat.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251731440.21104@natsu.mindrot.org>
 <55128A9D.3020507@redhat.com>
Message-ID: <alpine.BSO.2.11.1503252150510.21104@natsu.mindrot.org>

On Wed, 25 Mar 2015, Petr Lautrbach wrote:

> On 03/25/2015 08:23 AM, Damien Miller wrote:
> 
> > The source releases we make sit at the beginning of a very slow upgrade
> > pipe - your own numbers demonstrate that clearly. Ubuntu don't have
> > an LTS scheduled this year and Redhat (probably the worst offender at
> > keeping ancient OpenSSH on the Internet) haven't even announced their
> > next RHEL.
> > 
> 
> The Red Hat Enterprise Linux 7.1 with openssh-6.6.1p1 was released March
> 5, 2015.

ok, I take that back - I'm just scarred from the old 5.x versions
still supported in RHEL...

From matthew at debian.org  Thu Mar 26 01:32:34 2015
From: matthew at debian.org (Matthew Vernon)
Date: Wed, 25 Mar 2015 14:32:34 +0000
Subject: [Debian bug 781107] ssh-keygen -F return code has changed and
 is not documented
In-Reply-To: <alpine.BSO.2.11.1503250952390.21104@natsu.mindrot.org>
References: <5511ACE4.2040400@debian.org>
 <alpine.BSO.2.11.1503250952390.21104@natsu.mindrot.org>
Message-ID: <5512C702.8040801@debian.org>

On 24/03/15 22:53, Damien Miller wrote:
> On Tue, 24 Mar 2015, Matthew Vernon wrote:
> 
>> Hi,
>>
>> I tripped over the effects of commit 660854 [0] when moving some
>> infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible
>> module used "return 0, but no output" for 'host not found in known_hosts
>> file', and now complains that ssh-keygen is returning an error status. I
>> don't think this change in API was announced in the release notes?
>>
>> i.e. ssh-keygen -F foo.invalid -f ~/.ssh/known_hosts used to return 0
>> (and no output), and now returns 1 (and no output).
>>
>> Is the non-zero return code really helpful here?
> 
> Yes, it lets you tell whether the hostname is present in known_hosts.

Iff nothing else has gone wrong - ssh-keygen -F can return 1 in other
cases, as well. So you're still left with relying on an absence of
output, aren't you?

Regards,

Matthew

From matthew at debian.org  Thu Mar 26 02:31:27 2015
From: matthew at debian.org (Matthew Vernon)
Date: Wed, 25 Mar 2015 15:31:27 +0000
Subject: [Debian bug 781107] ssh-keygen -F return code has changed and
 is not documented
In-Reply-To: <alpine.BSO.2.11.1503250952390.21104@natsu.mindrot.org>
References: <5511ACE4.2040400@debian.org>
 <alpine.BSO.2.11.1503250952390.21104@natsu.mindrot.org>
Message-ID: <5512D4CF.6010300@debian.org>

On 24/03/15 22:53, Damien Miller wrote:
> On Tue, 24 Mar 2015, Matthew Vernon wrote:

>> Less controversially, could the return values of ssh-keygen and their
>> meanings be documented (and flagged when they change), please?
> 
> Sure, someone has to do the work though.

I had a look; ssh-keygen either exits 1 or 255 (via fatal). It's not
clear to me from reading the code what the rationale is for picking 1 or
255; what is the intended difference in meaning between these two errors
(or alternatively, how do you decide whether to call fatal or print and
error and exit(1))?

Thanks,

Matthew


From calestyo at scientia.net  Thu Mar 26 02:45:41 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Wed, 25 Mar 2015 16:45:41 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
Message-ID: <1427298341.10191.417.camel@scientia.net>

On Wed, 2015-03-25 at 18:48 +1100, Damien Miller wrote: 
> Our ability to influence people who run truly obsolete software is
> extremely limited.
+1, mostly because those who still use something that outdated in their
products are either dead, or simply don't care about their customer's
security (which is typical in the embedded devices area).
Just by us (or anyone else) saying anything, that won't change.

> The best we can do is deprecate as noisily as
> possible after extremely generous grace period. This is what we are
> doing
I think just deprecating is what has been done years ago - everyone can
by now truly know that SSH1 should not have been used since a long time.

I'd even support if you really remove the v1 related code from the
codebase. Just deactivating it per default and affected people will
simply enable it again, without bothering to do their homework.
And even if 6.9 would really lack v1 support, people could still just
use anything <6.9  for v1 - they won't be less secure.


:)

Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/e2d5b610/attachment.bin>

From alex at alex.org.uk  Thu Mar 26 03:46:47 2015
From: alex at alex.org.uk (Alex Bligh)
Date: Wed, 25 Mar 2015 16:46:47 +0000
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <1427253342.10191.405.camel@scientia.net>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <1427253342.10191.405.camel@scientia.net>
Message-ID: <303FBE2C-794C-4534-884E-C73550AB43A0@alex.org.uk>


On 25 Mar 2015, at 03:15, Christoph Anton Mitterer <calestyo at scientia.net> wrote:

> On Wed, 2015-03-25 at 10:26 +1100, Damien Miller wrote: 
>> OpenSSH git master now disabled SSH protocol 1 at compile time by
>> default. If you want it back, then you'll need to pass --with-ssh1
>> to configure before you build.
> +1
> 
> - People who use SSH are expected to want security (which v1 doesn't
> provide) - people wo actually don't want security, shouldn't have used
> SSH in the first place, but could have used rsh, telnet, etc.

+1 for doing it in sshd.

For the client, one issue is that it's not easy for the naive ssh
user to tell if the equipment they are using supports ssh2 or just
ssh1. For instance, the user currently using an ssh1-supporting
ssh client to reach their cisco router doesn't (as I understand it)
get warned if the cisco router only supports ssh1.

Would one option for the client to be to display a (suppressible)
'The server you are connecting to only supports ssh protocol
version 1 which is potentially insecure, and for which
support will soon be removed - continue (y/n)' type
prompt by default? This could continue for a couple of major
releases.

-- 
Alex Bligh




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/c2af731e/attachment.bin>

From dan at doxpara.com  Thu Mar 26 04:17:07 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 25 Mar 2015 10:17:07 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <303FBE2C-794C-4534-884E-C73550AB43A0@alex.org.uk>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <1427253342.10191.405.camel@scientia.net>
 <303FBE2C-794C-4534-884E-C73550AB43A0@alex.org.uk>
Message-ID: <CAEW7AC=PNONqQLBH13O89YMhx72o4U9REj3WPXfbGGE33higyw@mail.gmail.com>

I think we require ssh -1 to connect to SSHv1, but this is the sort of
thing that can get automated.

I think there's wide consensus on this move for sshd.  The only question is
ssh -1, I think.

On Wed, Mar 25, 2015 at 9:46 AM, Alex Bligh <alex at alex.org.uk> wrote:

>
> On 25 Mar 2015, at 03:15, Christoph Anton Mitterer <calestyo at scientia.net>
> wrote:
>
> > On Wed, 2015-03-25 at 10:26 +1100, Damien Miller wrote:
> >> OpenSSH git master now disabled SSH protocol 1 at compile time by
> >> default. If you want it back, then you'll need to pass --with-ssh1
> >> to configure before you build.
> > +1
> >
> > - People who use SSH are expected to want security (which v1 doesn't
> > provide) - people wo actually don't want security, shouldn't have used
> > SSH in the first place, but could have used rsh, telnet, etc.
>
> +1 for doing it in sshd.
>
> For the client, one issue is that it's not easy for the naive ssh
> user to tell if the equipment they are using supports ssh2 or just
> ssh1. For instance, the user currently using an ssh1-supporting
> ssh client to reach their cisco router doesn't (as I understand it)
> get warned if the cisco router only supports ssh1.
>
> Would one option for the client to be to display a (suppressible)
> 'The server you are connecting to only supports ssh protocol
> version 1 which is potentially insecure, and for which
> support will soon be removed - continue (y/n)' type
> prompt by default? This could continue for a couple of major
> releases.
>
> --
> Alex Bligh
>
>
>
>
>
> _______________________________________________
> 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 26 10:51:45 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 26 Mar 2015 10:51:45 +1100 (AEDT)
Subject: [Debian bug 781107] ssh-keygen -F return code has changed and
 is not documented
In-Reply-To: <5512D4CF.6010300@debian.org>
References: <5511ACE4.2040400@debian.org>
 <alpine.BSO.2.11.1503250952390.21104@natsu.mindrot.org>
 <5512D4CF.6010300@debian.org>
Message-ID: <alpine.BSO.2.11.1503261049560.22200@natsu.mindrot.org>

On Wed, 25 Mar 2015, Matthew Vernon wrote:

> I had a look; ssh-keygen either exits 1 or 255 (via fatal). It's not
> clear to me from reading the code what the rationale is for picking 1 or
> 255; what is the intended difference in meaning between these two errors
> (or alternatively, how do you decide whether to call fatal or print and
> error and exit(1))?

There's no rationale, just history. ssh-keygen probably needs
tidying more than any other part of the codebase.

IMO we should fatal() for errors and exit() only for cases where we
want to return a meaningful signal via the return value.

-d

From nkadel at gmail.com  Thu Mar 26 17:30:07 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 26 Mar 2015 02:30:07 -0400
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <1427298341.10191.417.camel@scientia.net>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
Message-ID: <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>

On Wed, Mar 25, 2015 at 11:45 AM, Christoph Anton Mitterer
<calestyo at scientia.net> wrote:
> On Wed, 2015-03-25 at 18:48 +1100, Damien Miller wrote:
>> Our ability to influence people who run truly obsolete software is
>> extremely limited.
> +1, mostly because those who still use something that outdated in their
> products are either dead, or simply don't care about their customer's
> security (which is typical in the embedded devices area).
> Just by us (or anyone else) saying anything, that won't change.
>
>> The best we can do is deprecate as noisily as
>> possible after extremely generous grace period. This is what we are
>> doing
> I think just deprecating is what has been done years ago - everyone can
> by now truly know that SSH1 should not have been used since a long time.
>
> I'd even support if you really remove the v1 related code from the
> codebase. Just deactivating it per default and affected people will
> simply enable it again, without bothering to do their homework.
> And even if 6.9 would really lack v1 support, people could still just
> use anything <6.9  for v1 - they won't be less secure.

Yanking it out wholesale should be part of a 7.0 build, not an
incremental release. That's a major incompatibility with one heck of a
lot of existing code, much of which is on extended support.

From aixtools at gmail.com  Thu Mar 26 21:19:28 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 26 Mar 2015 11:19:28 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAEW7ACmQrKOUvemPMtwrjfwCjG6BvsthOsc0r5Cc+i-aVrm+-g@mail.gmail.com>
 <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
Message-ID: <CANvxniX9kX0X=dhLze_w=PGrT75LWa+DZnMCvCSRzSO7Vo2NYw@mail.gmail.com>

My two-cents

removing v1 from the server - excellent.

removing it from the client - admirable, but there are many potential
operational concerns as mentioned above. I'll chat a bit about personal
experience with removal of something as being "more secure" when it's
effect is actually lessen "security"

Possible solution - even for beyond ?

Create a new client that only supports v1 protocol, and gives a 'nasty'
banner (depreciated, provided only for support of devices that do not
support v2, etc..) - This way, people are made consciously aware of the
weakness in their (old) device ssl support and/or of a poor configuration
(v2 disabled or not configured). Obviously, this client would/can not
communicate with the new servers that only support v2.

IMHO: part of security is making the user conscious of weaknesses and
motivating them to make change.

Experience: I have some hardware, on an internal network - that only
supports 40-bit ssl. I am forced to continue to use FF v17 because that was
the last browser to provide SSL40-bit support. My security is weakened
because I cannot update that browser, and I continue to lose plugins
because they do not support FF17 anymore. All other browsers stopped
support earlier as well.

So, complete removal, with no alternative means I cannot update to newer -
safer - technology. But security is three pronged:
Confidential, Integrity, and Availability. Removal of something such that
there is no alternative is equal to a security breach - I am an authorized
user, but no *availability *to access. -- Security broken - imho.

Michael

On Thu, Mar 26, 2015 at 7:30 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Wed, Mar 25, 2015 at 11:45 AM, Christoph Anton Mitterer
> <calestyo at scientia.net> wrote:
> > On Wed, 2015-03-25 at 18:48 +1100, Damien Miller wrote:
> >> Our ability to influence people who run truly obsolete software is
> >> extremely limited.
> > +1, mostly because those who still use something that outdated in their
> > products are either dead, or simply don't care about their customer's
> > security (which is typical in the embedded devices area).
> > Just by us (or anyone else) saying anything, that won't change.
> >
> >> The best we can do is deprecate as noisily as
> >> possible after extremely generous grace period. This is what we are
> >> doing
> > I think just deprecating is what has been done years ago - everyone can
> > by now truly know that SSH1 should not have been used since a long time.
> >
> > I'd even support if you really remove the v1 related code from the
> > codebase. Just deactivating it per default and affected people will
> > simply enable it again, without bothering to do their homework.
> > And even if 6.9 would really lack v1 support, people could still just
> > use anything <6.9  for v1 - they won't be less secure.
>
> Yanking it out wholesale should be part of a 7.0 build, not an
> incremental release. That's a major incompatibility with one heck of a
> lot of existing code, much of which is on extended support.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From aixtools at gmail.com  Thu Mar 26 21:27:02 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 26 Mar 2015 11:27:02 +0100
Subject: [Bug 2371] New: make check fails when using --without-openssl on
 AIX
In-Reply-To: <bug-2371-705@https.bugzilla.mindrot.org/>
References: <bug-2371-705@https.bugzilla.mindrot.org/>
Message-ID: <CANvxniXgpLgdEPt-N3XOiNhbvVJNLfb_1RZJWADRdNtC=xgETQ@mail.gmail.com>

FYI - when built without --without-openssl (please forgive the 'double
negative') --

make[1]: Leaving directory `/data/prj/openbsd/openssh/openssh-6.8p1/regress'
all tests passed


On Tue, Mar 24, 2015 at 10:30 PM, <bugzilla-daemon at mindrot.org> wrote:

> https://bugzilla.mindrot.org/show_bug.cgi?id=2371
>
>             Bug ID: 2371
>            Summary: make check fails when using --without-openssl on AIX
>            Product: Portable OpenSSH
>            Version: 6.9p1
>           Hardware: Other
>                 OS: All
>             Status: NEW
>           Severity: normal
>           Priority: P5
>          Component: Build system
>           Assignee: unassigned-bugs at mindrot.org
>           Reporter: aixtools at gmail.com
>
> During the RC check everything worked fine - except I had never tested
> --without-openssl (which I know is experimental according to changelog)
>
> However, I cannot verify the stability of OpenSSH because 'make tests'
> fails with the following message.
>
>         xlc -I/opt/include -I/opt/aixtools/include -O2  -I. -I.
> -I/opt/include -DSSHDIR=\"/var//etc\"
> -D_PATH_SSH_PROGRAM=\"/opt/bin/ssh\"
> -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/libexec/ssh-askpass\"
> -D_PATH_SFTP_SERVER=\"/opt/libexec/sftp-server\"
> -D_PATH_SSH_KEY_SIGN=\"/opt/libexec/ssh-keysign\"
> -D_PATH_SSH_PKCS11_HELPER=\"/opt/libexec/ssh-pkcs11-helper\"
> -D_PATH_SSH_PIDDIR=\"/var//etc\"
> -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c
> regress/unittests/test_helper/fuzz.c -o
> regress/unittests/test_helper/fuzz.o
>         /usr/bin/ar rv regress/unittests/test_helper/libtest_helper.a
> regress/unittests/test_helper/test_helper.o
> regress/unittests/test_helper/fuzz.o
> ar: Creating an archive file
> regress/unittests/test_helper/libtest_helper.a.
> a - regress/unittests/test_helper/test_helper.o
> a - regress/unittests/test_helper/fuzz.o
>         ranlib regress/unittests/test_helper/libtest_helper.a
>         xlc -o regress/unittests/sshbuf/test_sshbuf -L.
> -Lopenbsd-compat/  -blibpath:/usr/lib:/lib
> regress/unittests/sshbuf/tests.o
> regress/unittests/sshbuf/test_sshbuf.o
> regress/unittests/sshbuf/test_sshbuf_getput_basic.o
> regress/unittests/sshbuf/test_sshbuf_getput_crypto.o
> regress/unittests/sshbuf/test_sshbuf_misc.o
> regress/unittests/sshbuf/test_sshbuf_fuzz.o
> regress/unittests/sshbuf/test_sshbuf_getput_fuzz.o
> regress/unittests/sshbuf/test_sshbuf_fixed.o
> regress/unittests/test_helper/libtest_helper.a  -lssh -lopenbsd-compat
> -lssh -lopenbsd-compat -lz  -lcrypt
> ld: 0711-317 ERROR: Undefined symbol: .BN_hex2bn
> ld: 0711-317 ERROR: Undefined symbol: .BN_num_bits
> ld: 0711-317 ERROR: Undefined symbol: .BN_bn2bin
> ld: 0711-317 ERROR: Undefined symbol: .BN_bin2bn
> ld: 0711-317 ERROR: Undefined symbol: .BN_free
> ld: 0711-317 ERROR: Undefined symbol: .BN_new
> ld: 0711-317 ERROR: Undefined symbol: .BN_clear_free
> ld: 0711-317 ERROR: Undefined symbol: .BN_cmp
> ld: 0711-317 ERROR: Undefined symbol: .BN_bn2hex
> ld: 0711-317 ERROR: Undefined symbol: .ERR_get_error
> ld: 0711-317 ERROR: Undefined symbol: .ERR_error_string
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.
> make: 1254-004 The error code from the last command is 8.
>
>
> Stop.
>
> However, ssh does compile. - so my hope is that OpenSSH is valid, but
> the test system is broken.
>
> root at x064:[/data/prj/openbsd/openssh/openssh-6.8p1]./ssh -V
> OpenSSH_6.8p1, without OpenSSL
>
> --
> You are receiving this mail because:
> You are watching the assignee of the bug.
> _______________________________________________
> openssh-bugs mailing list
> openssh-bugs at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-bugs
>

From johannes at kyriasis.com  Fri Mar 27 00:10:15 2015
From: johannes at kyriasis.com (Johannes =?utf-8?B?TMO2dGhiZXJn?=)
Date: Thu, 26 Mar 2015 14:10:15 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
References: <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
Message-ID: <20150326131015.GA4430@leeloo.kyriasis.com>

On 26/03, Nico Kadel-Garcia wrote:
>Yanking it out wholesale should be part of a 7.0 build, not an
>incremental release. That's a major incompatibility with one heck of a
>lot of existing code, much of which is on extended support.
>

And it?s been said multiple times in this thread that the OpenSSH 
version number is just a incrementing decimal number, it doesn?t have 
any major or minor releases.

-- 
Sincerely,
  Johannes L?thberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  https://theos.kyriasis.com/~kyrias/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1495 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150326/abc34619/attachment.bin>

From dan at doxpara.com  Fri Mar 27 04:19:05 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 26 Mar 2015 10:19:05 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150326131015.GA4430@leeloo.kyriasis.com>
References: <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
Message-ID: <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>

Communication is a two way street.  If OpenSSH wants to go down the route
of single releases, like the browsers did, it can remove its minor numbers,
like the browsers did.

Everything else is a debate but this isn't.  Don't say a thing and say you
didn't just say it.

On Thu, Mar 26, 2015 at 6:10 AM, Johannes L?thberg <johannes at kyriasis.com>
wrote:

> On 26/03, Nico Kadel-Garcia wrote:
>
>> Yanking it out wholesale should be part of a 7.0 build, not an
>> incremental release. That's a major incompatibility with one heck of a
>> lot of existing code, much of which is on extended support.
>>
>>
> And it?s been said multiple times in this thread that the OpenSSH version
> number is just a incrementing decimal number, it doesn?t have any major or
> minor releases.
>
> --
> Sincerely,
>  Johannes L?thberg
>  PGP Key ID: 0x50FB9B273A9D0BB5
>  https://theos.kyriasis.com/~kyrias/
>
> _______________________________________________
> 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 27 05:44:37 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 26 Mar 2015 11:44:37 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
References: <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
Message-ID: <20150326184437.GA6009@linux124.nas.nasa.gov>

On Thu, Mar 26, 2015 at 10:19:05 -0700, Dan Kaminsky wrote:
> Communication is a two way street.  If OpenSSH wants to go down the route
> of single releases, like the browsers did, it can remove its minor numbers,
> like the browsers did.
> 

There's no question of "going down the route." This has been the
practice with OpenSSH for many years -- if not from the beginning.

Certainly, those outside of the OpenSSH development community often
assume the major/minor release scheme used by the majority of open
source projects, but I'm suprised to see such confusion on this list.

As to disabling SSH v1, hurray! The protocol has been long-obsolete and
it is well-known to be insecure. Sure, some will eventually be impacted
by this, but maybe that is a good thing. Perhaps it will give a little
more incentive for those who are still using SSH1 to move into this
century.

-- 
Iain Morgan

From dan at doxpara.com  Fri Mar 27 05:55:18 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 26 Mar 2015 11:55:18 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150326184437.GA6009@linux124.nas.nasa.gov>
References: <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
Message-ID: <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>

You're right.  My argument the is the next build of OpenSSH should be
OpenSSH 7, and the one after that 8, then 9, then 10.  No minor releases?
Sure, go ahead.  Deprecate the point,

Do you manage any machines running SSHv1?

On Thu, Mar 26, 2015 at 11:44 AM, Iain Morgan <imorgan at nas.nasa.gov> wrote:

> On Thu, Mar 26, 2015 at 10:19:05 -0700, Dan Kaminsky wrote:
> > Communication is a two way street.  If OpenSSH wants to go down the route
> > of single releases, like the browsers did, it can remove its minor
> numbers,
> > like the browsers did.
> >
>
> There's no question of "going down the route." This has been the
> practice with OpenSSH for many years -- if not from the beginning.
>
> Certainly, those outside of the OpenSSH development community often
> assume the major/minor release scheme used by the majority of open
> source projects, but I'm suprised to see such confusion on this list.
>
> As to disabling SSH v1, hurray! The protocol has been long-obsolete and
> it is well-known to be insecure. Sure, some will eventually be impacted
> by this, but maybe that is a good thing. Perhaps it will give a little
> more incentive for those who are still using SSH1 to move into this
> century.
>
> --
> Iain Morgan
>

From imorgan at nas.nasa.gov  Fri Mar 27 06:43:40 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 26 Mar 2015 12:43:40 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
References: <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
Message-ID: <20150326194340.GA6011@linux124.nas.nasa.gov>

On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote:
> You're right.  My argument the is the next build of OpenSSH should be
> OpenSSH 7, and the one after that 8, then 9, then 10.  No minor releases?
> Sure, go ahead.  Deprecate the point,
> 
> Do you manage any machines running SSHv1?
> 

If by "running" you mean accepting SSH1, of course not. From a security
perspective, no one should be using SSH1.

For those who, for whatever reason, need to support systems that only
support SSH1, there are already sufficient solutions that have been
noted multiple times on this list.

Those who are still using SSH1 have already demonstrated the fact that
they are slow to embrace new technology, so I would not be surprised to
find that the majority of them are also slow to upgrade to newer
versions of OpenSSH. I would also not be surprised to find that many of
them are still using telnet to manage their routers.

-- 
Iain Morgan

From alex at alex.org.uk  Fri Mar 27 07:11:28 2015
From: alex at alex.org.uk (Alex Bligh)
Date: Thu, 26 Mar 2015 20:11:28 +0000
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150326194340.GA6011@linux124.nas.nasa.gov>
References: <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
Message-ID: <39729E7F-4C84-4197-BC3E-3FE68511B12B@alex.org.uk>


On 26 Mar 2015, at 19:43, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> Those who are still using SSH1 have already demonstrated the fact that
> they are slow to embrace new technology, so I would not be surprised to
> find that the majority of them are also slow to upgrade to newer
> versions of OpenSSH. I would also not be surprised to find that many of
> them are still using telnet to manage their routers.

Really?

I use ssh2 everywhere (obviously). Occasionally I need to connect to
an old Cisco box that cannot be upgraded to support new ssh protocols
because it the flash is not large enough. It's locked down by IP
address, and behind a firewall, but the only option other than ssh is
telnet. I'd like my normal client to support sshv2 and sshv1. I don't mind
having to explicitly request this on the command line, nor do
I mind warnings. I don't think this use case is particularly unusual
given ssh is a 'swiss army knife' tool. Does the fact I still like
my odd-tool-that-removes-the-stones-from-horses-hooves make me
slow to embrace the shiny sharp blade?

Or (to put this another way) - fine, disable at compile-time
by default if you want. But please also make it possible to
have it compiled in but produce a warning and require explicit
confirmation or something. This would encourage the distros
to choose either one of those things, rather than simply
change the compilation option back.

-- 
Alex Bligh





From imorgan at nas.nasa.gov  Fri Mar 27 07:59:27 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 26 Mar 2015 13:59:27 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <39729E7F-4C84-4197-BC3E-3FE68511B12B@alex.org.uk>
References: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
 <39729E7F-4C84-4197-BC3E-3FE68511B12B@alex.org.uk>
Message-ID: <20150326205927.GB6011@linux124.nas.nasa.gov>

On Thu, Mar 26, 2015 at 20:11:28 +0000, Alex Bligh wrote:
> 
> On 26 Mar 2015, at 19:43, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> > Those who are still using SSH1 have already demonstrated the fact that
> > they are slow to embrace new technology, so I would not be surprised to
> > find that the majority of them are also slow to upgrade to newer
> > versions of OpenSSH. I would also not be surprised to find that many of
> > them are still using telnet to manage their routers.
> 
> Really?
> 
> I use ssh2 everywhere (obviously). Occasionally I need to connect to
> an old Cisco box that cannot be upgraded to support new ssh protocols
> because it the flash is not large enough. It's locked down by IP
> address, and behind a firewall, but the only option other than ssh is
> telnet. I'd like my normal client to support sshv2 and sshv1. I don't mind
> having to explicitly request this on the command line, nor do
> I mind warnings. I don't think this use case is particularly unusual
> given ssh is a 'swiss army knife' tool. Does the fact I still like
> my odd-tool-that-removes-the-stones-from-horses-hooves make me
> slow to embrace the shiny sharp blade?
> 
> Or (to put this another way) - fine, disable at compile-time
> by default if you want. But please also make it possible to
> have it compiled in but produce a warning and require explicit
> confirmation or something. This would encourage the distros
> to choose either one of those things, rather than simply
> change the compilation option back.
> 
> -- 
> Alex Bligh
> 

So, there's already a compile-time option to enable SSH1 support. And, I
rather suspect that some OS distributors will enable tht option by
default and others might provide both flavors. This is merely a change
to the default for OpenBSD and stock portable OpenSSH.

-- 
Iain Morgan

From dan at doxpara.com  Fri Mar 27 08:05:08 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 26 Mar 2015 14:05:08 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150326194340.GA6011@linux124.nas.nasa.gov>
References: <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
Message-ID: <CAEW7ACkUzXfV8G1AEasNKtu7VXUSrfjMDSxxKcQ1kebEOei+AA@mail.gmail.com>

So, this isn't your problem and you don't respect the people's whose
problem it is.

On Thu, Mar 26, 2015 at 12:43 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:

> On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote:
> > You're right.  My argument the is the next build of OpenSSH should be
> > OpenSSH 7, and the one after that 8, then 9, then 10.  No minor releases?
> > Sure, go ahead.  Deprecate the point,
> >
> > Do you manage any machines running SSHv1?
> >
>
> If by "running" you mean accepting SSH1, of course not. From a security
> perspective, no one should be using SSH1.
>
> For those who, for whatever reason, need to support systems that only
> support SSH1, there are already sufficient solutions that have been
> noted multiple times on this list.
>
> Those who are still using SSH1 have already demonstrated the fact that
> they are slow to embrace new technology, so I would not be surprised to
> find that the majority of them are also slow to upgrade to newer
> versions of OpenSSH. I would also not be surprised to find that many of
> them are still using telnet to manage their routers.
>
> --
> Iain Morgan
>

From djm at mindrot.org  Fri Mar 27 09:00:07 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 27 Mar 2015 09:00:07 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
References: <alpine.BSO.2.11.1503251230140.21104@natsu.mindrot.org>
 <CAEW7ACnF7HPehsTEshXWLnna7GFXLRf5Xn4tTaDBq+yGb+EkbA@mail.gmail.com>
 <CAOCN9rxv1QBx4OhOUVLYMHZdGn1HTFnxL7MA+vcAzARR_3qE+A@mail.gmail.com>
 <alpine.BSO.2.11.1503251408240.21104@natsu.mindrot.org>
 <CAEW7AC=G8N7pOLcHa300o2wuHxo-SL8uwvHQoh0H7FwHmpSTOA@mail.gmail.com>
 <alpine.BSO.2.11.1503251615270.21104@natsu.mindrot.org>
 <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503270859300.22200@natsu.mindrot.org>

On Thu, 26 Mar 2015, Dan Kaminsky wrote:

> Communication is a two way street.  If OpenSSH wants to go down the route
> of single releases, like the browsers did, it can remove its minor numbers,
> like the browsers did.
> 
> Everything else is a debate but this isn't.  Don't say a thing and say you
> didn't just say it.

We said it back around openssh-3.0. This is ancient history that we certainly
aren't revisiting.

From nicolas at caniart.net  Fri Mar 27 09:00:39 2015
From: nicolas at caniart.net (Nicolas CANIART)
Date: Thu, 26 Mar 2015 23:00:39 +0100
Subject: Ssh forced command for system users.
Message-ID: <CAOWzrLAQ8CYL7c+73Ox22wQZVrpKJRqQxq=4iWjNThoEZSPD8w@mail.gmail.com>

Hi !

  I just notice this behaviour (I guess I was not paying enough
attention). While working on setting up integration testing for a
project of mine, that works through ssh, I had issues that I could not
reproduce on my development machine. The problem stemmed in the fact
that the CI system running the test suite is a user with its shell set
to /usr/sbin/nologin (Buildbot, on a Debian system, but OpenBSD's
_buildslave user has a similar with its shell set to /sbin/nologin).

When a user is set-up this way, setting a forced command in its
~/.ssh/authorized_keys file is pointless. Indeed ssh launches the
forced command through a shell. Which shell is launched is
determined with getpwnam, which returns /usr/sbin/nologin. Thus the failure.

I was wondering why SSH uses a shell to start a forced command (one
hypothesis I have is to
set up a proper environment for the subsequent session (setting PATH,
HOME, ...), which I think
SSH does not do. Does this not counter-act the purpose of forced command ?

On the other side what are the real benefits, security-wise, of
setting the users shell to /sbin/nologin (or similar command from),
apart from: preventing local log in or preventing the use system(2)
(why does this still exists !?), but which may not be a small threat
given how many scripting languages still binds it.

Any comments ? Any ways to circumvent this ? Or shouldn't ssh not use
a shell to launch forced commands ? I looked in the archive, and its
seems to me this issue has not been raised before. My apologies if it
has.

Regards,
Nicolas.

From imorgan at nas.nasa.gov  Fri Mar 27 09:12:40 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 26 Mar 2015 15:12:40 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7ACkUzXfV8G1AEasNKtu7VXUSrfjMDSxxKcQ1kebEOei+AA@mail.gmail.com>
References: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
 <CAEW7ACkUzXfV8G1AEasNKtu7VXUSrfjMDSxxKcQ1kebEOei+AA@mail.gmail.com>
Message-ID: <20150326221240.GE6011@linux124.nas.nasa.gov>

No, I just think 15 years or so is more than enough time to have
addressed the issue.

On Thu, Mar 26, 2015 at 14:05:08 -0700, Dan Kaminsky wrote:
> So, this isn't your problem and you don't respect the people's whose
> problem it is.
> 
> On Thu, Mar 26, 2015 at 12:43 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> 
> > On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote:
> > > You're right.  My argument the is the next build of OpenSSH should be
> > > OpenSSH 7, and the one after that 8, then 9, then 10.  No minor releases?
> > > Sure, go ahead.  Deprecate the point,
> > >
> > > Do you manage any machines running SSHv1?
> > >
> >
> > If by "running" you mean accepting SSH1, of course not. From a security
> > perspective, no one should be using SSH1.
> >
> > For those who, for whatever reason, need to support systems that only
> > support SSH1, there are already sufficient solutions that have been
> > noted multiple times on this list.
> >
> > Those who are still using SSH1 have already demonstrated the fact that
> > they are slow to embrace new technology, so I would not be surprised to
> > find that the majority of them are also slow to upgrade to newer
> > versions of OpenSSH. I would also not be surprised to find that many of
> > them are still using telnet to manage their routers.
> >
> > --
> > Iain Morgan
> >

-- 
Iain Morgan

From dan at doxpara.com  Fri Mar 27 09:27:27 2015
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 26 Mar 2015 15:27:27 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150326221240.GE6011@linux124.nas.nasa.gov>
References: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
 <CAEW7ACkUzXfV8G1AEasNKtu7VXUSrfjMDSxxKcQ1kebEOei+AA@mail.gmail.com>
 <20150326221240.GE6011@linux124.nas.nasa.gov>
Message-ID: <CAEW7AC=D=dcXqo6uMO6uVOnQw+_eYAiYA-50rFp0X5cvuNFHRw@mail.gmail.com>

Do you have a problem with 15 year old cars?

On Thu, Mar 26, 2015 at 3:12 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:

> No, I just think 15 years or so is more than enough time to have
> addressed the issue.
>
> On Thu, Mar 26, 2015 at 14:05:08 -0700, Dan Kaminsky wrote:
> > So, this isn't your problem and you don't respect the people's whose
> > problem it is.
> >
> > On Thu, Mar 26, 2015 at 12:43 PM, Iain Morgan <imorgan at nas.nasa.gov>
> wrote:
> >
> > > On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote:
> > > > You're right.  My argument the is the next build of OpenSSH should be
> > > > OpenSSH 7, and the one after that 8, then 9, then 10.  No minor
> releases?
> > > > Sure, go ahead.  Deprecate the point,
> > > >
> > > > Do you manage any machines running SSHv1?
> > > >
> > >
> > > If by "running" you mean accepting SSH1, of course not. From a security
> > > perspective, no one should be using SSH1.
> > >
> > > For those who, for whatever reason, need to support systems that only
> > > support SSH1, there are already sufficient solutions that have been
> > > noted multiple times on this list.
> > >
> > > Those who are still using SSH1 have already demonstrated the fact that
> > > they are slow to embrace new technology, so I would not be surprised to
> > > find that the majority of them are also slow to upgrade to newer
> > > versions of OpenSSH. I would also not be surprised to find that many of
> > > them are still using telnet to manage their routers.
> > >
> > > --
> > > Iain Morgan
> > >
>
> --
> Iain Morgan
>

From imorgan at nas.nasa.gov  Fri Mar 27 09:32:22 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 26 Mar 2015 15:32:22 -0700
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CAEW7AC=D=dcXqo6uMO6uVOnQw+_eYAiYA-50rFp0X5cvuNFHRw@mail.gmail.com>
References: <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
 <CAEW7ACkUzXfV8G1AEasNKtu7VXUSrfjMDSxxKcQ1kebEOei+AA@mail.gmail.com>
 <20150326221240.GE6011@linux124.nas.nasa.gov>
 <CAEW7AC=D=dcXqo6uMO6uVOnQw+_eYAiYA-50rFp0X5cvuNFHRw@mail.gmail.com>
Message-ID: <20150326223222.GF6011@linux124.nas.nasa.gov>

Non sequitor.

On Thu, Mar 26, 2015 at 15:27:27 -0700, Dan Kaminsky wrote:
> Do you have a problem with 15 year old cars?
> 
> On Thu, Mar 26, 2015 at 3:12 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> 
> > No, I just think 15 years or so is more than enough time to have
> > addressed the issue.
> >
> > On Thu, Mar 26, 2015 at 14:05:08 -0700, Dan Kaminsky wrote:
> > > So, this isn't your problem and you don't respect the people's whose
> > > problem it is.
> > >
> > > On Thu, Mar 26, 2015 at 12:43 PM, Iain Morgan <imorgan at nas.nasa.gov>
> > wrote:
> > >
> > > > On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote:
> > > > > You're right.  My argument the is the next build of OpenSSH should be
> > > > > OpenSSH 7, and the one after that 8, then 9, then 10.  No minor
> > releases?
> > > > > Sure, go ahead.  Deprecate the point,
> > > > >
> > > > > Do you manage any machines running SSHv1?
> > > > >
> > > >
> > > > If by "running" you mean accepting SSH1, of course not. From a security
> > > > perspective, no one should be using SSH1.
> > > >
> > > > For those who, for whatever reason, need to support systems that only
> > > > support SSH1, there are already sufficient solutions that have been
> > > > noted multiple times on this list.
> > > >
> > > > Those who are still using SSH1 have already demonstrated the fact that
> > > > they are slow to embrace new technology, so I would not be surprised to
> > > > find that the majority of them are also slow to upgrade to newer
> > > > versions of OpenSSH. I would also not be surprised to find that many of
> > > > them are still using telnet to manage their routers.
> > > >
> > > > --
> > > > Iain Morgan
> > > >
> >
> > --
> > Iain Morgan
> >

-- 
Iain Morgan

From keisial at gmail.com  Fri Mar 27 10:24:09 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 27 Mar 2015 00:24:09 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
Message-ID: <55149519.8020203@gmail.com>

On 25/03/15 00:26, Damien Miller wrote:
> Hi,
>
> OpenSSH git master now disabled SSH protocol 1 at compile time by
> default. If you want it back, then you'll need to pass --with-ssh1
> to configure before you build.
>
> We expect to ship this configuration for openssh-6.9 in a few
> months.
>
> -d
>
At the latest I see at anongit.mindrot, 
5c27e3b6ec2db711dfcd40e6359c0bcdd0b62ea9
configure option is --without-ssh1, with ssh1 _enabled_ by default. What 
am I missing?


From keisial at gmail.com  Fri Mar 27 10:26:57 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 27 Mar 2015 00:26:57 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150326205927.GB6011@linux124.nas.nasa.gov>
References: <CAEW7AC=6wyfFtgp62ypby5m9_y0a_N46LCGgnPfo7uCWY24RGA@mail.gmail.com>
 <alpine.BSO.2.11.1503251838110.21104@natsu.mindrot.org>
 <1427298341.10191.417.camel@scientia.net>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <20150326131015.GA4430@leeloo.kyriasis.com>
 <CAEW7AC=cFt8V1kUqYm-CH47mvP4OB_5DqJ6jYF6J1cz3Pwp+4Q@mail.gmail.com>
 <20150326184437.GA6009@linux124.nas.nasa.gov>
 <CAEW7AC=CfhOs25htEEBsfqZpU51VwztSRZR_GpKsnfgE4HC_ZA@mail.gmail.com>
 <20150326194340.GA6011@linux124.nas.nasa.gov>
 <39729E7F-4C84-4197-BC3E-3FE68511B12B@alex.org.uk>
 <20150326205927.GB6011@linux124.nas.nasa.gov>
Message-ID: <551495C1.8020403@gmail.com>

On 26/03/15 21:59, Iain Morgan wrote:
> So, there's already a compile-time option to enable SSH1 support. And, I
> rather suspect that some OS distributors will enable tht option by
> default and others might provide both flavors. This is merely a change
> to the default for OpenBSD and stock portable OpenSSH.
IMHO it's important not only to provide an option to disable or enable 
ssh1-wide
support, but also easy configure switch so ssh is built with ssh1 
support but
sshd is built without it. Otherwise, I foresee a number of distros to 
enable ssh1
for both when they are interested just on client support.


From djm at mindrot.org  Fri Mar 27 12:04:37 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 27 Mar 2015 12:04:37 +1100 (AEDT)
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <55149519.8020203@gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <55149519.8020203@gmail.com>
Message-ID: <alpine.BSO.2.11.1503271204210.22200@natsu.mindrot.org>

On Fri, 27 Mar 2015, ?ngel Gonz?lez wrote:

> On 25/03/15 00:26, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH git master now disabled SSH protocol 1 at compile time by
> > default. If you want it back, then you'll need to pass --with-ssh1
> > to configure before you build.
> > 
> > We expect to ship this configuration for openssh-6.9 in a few
> > months.
> > 
> > -d
> > 
> At the latest I see at anongit.mindrot,
> 5c27e3b6ec2db711dfcd40e6359c0bcdd0b62ea9
> configure option is --without-ssh1, with ssh1 _enabled_ by default. What am I
> missing?

it's not you, it's me (forgot to push to the mirrors)

From hkario at redhat.com  Fri Mar 27 22:53:05 2015
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 27 Mar 2015 12:53:05 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <CANvxniX9kX0X=dhLze_w=PGrT75LWa+DZnMCvCSRzSO7Vo2NYw@mail.gmail.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <CANvxniX9kX0X=dhLze_w=PGrT75LWa+DZnMCvCSRzSO7Vo2NYw@mail.gmail.com>
Message-ID: <5194613.qjudOLPiy3@pintsize.usersys.redhat.com>

On Thursday 26 March 2015 11:19:28 Michael Felt wrote:
> Experience: I have some hardware, on an internal network - that only
> supports 40-bit ssl. I am forced to continue to use FF v17 because that was
> the last browser to provide SSL40-bit support. My security is weakened
> because I cannot update that browser, and I continue to lose plugins
> because they do not support FF17 anymore. All other browsers stopped
> support earlier as well.

Please put the device behind a stunnel and don't put yourself at risk.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150327/c503c5cd/attachment.bin>

From gert at greenie.muc.de  Sat Mar 28 00:15:47 2015
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 27 Mar 2015 14:15:47 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <5194613.qjudOLPiy3@pintsize.usersys.redhat.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <CAOCN9rzuRWvD2TuwrSK9pNw5dKDKw3P+1MqesfG9VvZuAecxjA@mail.gmail.com>
 <CANvxniX9kX0X=dhLze_w=PGrT75LWa+DZnMCvCSRzSO7Vo2NYw@mail.gmail.com>
 <5194613.qjudOLPiy3@pintsize.usersys.redhat.com>
Message-ID: <20150327131547.GH21893@greenie.muc.de>

Hi,

On Fri, Mar 27, 2015 at 12:53:05PM +0100, Hubert Kario wrote:
> On Thursday 26 March 2015 11:19:28 Michael Felt wrote:
> > Experience: I have some hardware, on an internal network - that only
> > supports 40-bit ssl. I am forced to continue to use FF v17 because that was
> > the last browser to provide SSL40-bit support. My security is weakened
> > because I cannot update that browser, and I continue to lose plugins
> > because they do not support FF17 anymore. All other browsers stopped
> > support earlier as well.
> 
> Please put the device behind a stunnel and don't put yourself at risk.

I don't think Michael is accessing that device over the Internet - but even
*in house* some devices force you to jump through such hoops.

Like, old HP ILO that you can't get updates for, that insist on using SSL,
but then fail to interoperate with recent browsers.  So what are you going
to do?  "Throw away a perfectly working and secure machine, because its
out of band interface is crap" or "keep around an old and insecure browser"?

Same thing with needing sshv1 to access old network gear where even sshv1
was an achievement.  "Throw away gear that does its job perfectly well,
but has no sshv2 for *management*" or "keep around an ssh v1 capable 
client"?

I, for one, need to explain why I buy new gear, and "because the out of
band / management access only does sshv1" is not a good reason for my 
management ("then just use telnet, no?")...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From hkario at redhat.com  Sat Mar 28 00:36:50 2015
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 27 Mar 2015 14:36:50 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150327131547.GH21893@greenie.muc.de>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <5194613.qjudOLPiy3@pintsize.usersys.redhat.com>
 <20150327131547.GH21893@greenie.muc.de>
Message-ID: <1725770.eLHRcz5pDi@pintsize.usersys.redhat.com>

On Friday 27 March 2015 14:15:47 Gert Doering wrote:
> Hi,
> 
> On Fri, Mar 27, 2015 at 12:53:05PM +0100, Hubert Kario wrote:
> > On Thursday 26 March 2015 11:19:28 Michael Felt wrote:
> > > Experience: I have some hardware, on an internal network - that only
> > > supports 40-bit ssl. I am forced to continue to use FF v17 because that
> > > was
> > > the last browser to provide SSL40-bit support. My security is weakened
> > > because I cannot update that browser, and I continue to lose plugins
> > > because they do not support FF17 anymore. All other browsers stopped
> > > support earlier as well.
> > 
> > Please put the device behind a stunnel and don't put yourself at risk.
> 
> I don't think Michael is accessing that device over the Internet - but even
> *in house* some devices force you to jump through such hoops.

the fact that he mentions usage of extensions, I'm not so sure he uses it only 
for internal out-of-band management sites...
 
> Like, old HP ILO that you can't get updates for, that insist on using SSL,
> but then fail to interoperate with recent browsers.  So what are you going
> to do?  "Throw away a perfectly working and secure machine, because its
> out of band interface is crap" or "keep around an old and insecure browser"?

such interfaces should be on a network of their own, as such you should go 
through a router to be able to connect to them. On same router you can put the 
stunnel or a redirect to other machine that does the tunneling to make sure 
the insecure connections from trusted network are not routed over regular 
network (be it company internal or Internet)

> Same thing with needing sshv1 to access old network gear where even sshv1
> was an achievement.  "Throw away gear that does its job perfectly well,
> but has no sshv2 for *management*" or "keep around an ssh v1 capable
> client"?

If you depend on hardware like this, you should have support* for it. Exactly 
because issues like this.

 * - where "support" means that either you have other people responsible for 
fixing it or that you can hire other people to fix it as the need arises
-- 
Regards,
Hubert Kario
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150327/a0bbba81/attachment.bin>

From gert at greenie.muc.de  Sat Mar 28 00:45:13 2015
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 27 Mar 2015 14:45:13 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <1725770.eLHRcz5pDi@pintsize.usersys.redhat.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <5194613.qjudOLPiy3@pintsize.usersys.redhat.com>
 <20150327131547.GH21893@greenie.muc.de>
 <1725770.eLHRcz5pDi@pintsize.usersys.redhat.com>
Message-ID: <20150327134513.GI21893@greenie.muc.de>

Hi,

On Fri, Mar 27, 2015 at 02:36:50PM +0100, Hubert Kario wrote:
> > Same thing with needing sshv1 to access old network gear where even sshv1
> > was an achievement.  "Throw away gear that does its job perfectly well,
> > but has no sshv2 for *management*" or "keep around an ssh v1 capable
> > client"?
> 
> If you depend on hardware like this, you should have support* for it. Exactly 
> because issues like this.
> 
>  * - where "support" means that either you have other people responsible for 
> fixing it or that you can hire other people to fix it as the need arises

You *definitely* need some real world exposure to the world of closed
source :-) - really.  

Try opening a case with HP that their ILO is broken and stupid, and they 
will happily sell you a new machine with a less broken ILO (or "differently"
broken), but not do stuff like "add sane ciphers to an ILO2".  Same for 
Cisco - of course you can buy a new machine with SSHv2, but for the old 
one, they will do hardware replacement if it breaks, but no "new features 
in the software"...

Yes, it would be so cool if we could just pay someone to put Linux on 
our routing gear and give us a SSHv2 server (without breaking the functions
that the device is important for, like "routing").  Right.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From hkario at redhat.com  Sat Mar 28 01:02:05 2015
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 27 Mar 2015 15:02:05 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150327134513.GI21893@greenie.muc.de>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <1725770.eLHRcz5pDi@pintsize.usersys.redhat.com>
 <20150327134513.GI21893@greenie.muc.de>
Message-ID: <6292251.3B6VXmd6Kx@pintsize.usersys.redhat.com>

On Friday 27 March 2015 14:45:13 Gert Doering wrote:
> Hi,
> 
> On Fri, Mar 27, 2015 at 02:36:50PM +0100, Hubert Kario wrote:
> > > Same thing with needing sshv1 to access old network gear where even
> > > sshv1
> > > was an achievement.  "Throw away gear that does its job perfectly well,
> > > but has no sshv2 for *management*" or "keep around an ssh v1 capable
> > > client"?
> > 
> > If you depend on hardware like this, you should have support* for it.
> > Exactly because issues like this.
> > 
> >  * - where "support" means that either you have other people responsible
> >  for
> > 
> > fixing it or that you can hire other people to fix it as the need arises
>
> Try opening a case with HP that their ILO is broken and stupid, and they
> will happily sell you a new machine with a less broken ILO (or "differently"
> broken), but not do stuff like "add sane ciphers to an ILO2".  Same for
> Cisco - of course you can buy a new machine with SSHv2, but for the old
> one, they will do hardware replacement if it breaks, but no "new features
> in the software"...

then vote with your wallet

as long as you keep buying broken hardware, they will keep selling broken 
hardware

> Yes, it would be so cool if we could just pay someone to put Linux on
> our routing gear and give us a SSHv2 server (without breaking the functions
> that the device is important for, like "routing").  Right.

Linux can work as a router. And nowadays most of network appliances are just 
regular x86 PCs with nice GUI on top.

-- 
Regards,
Hubert Kario
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150327/19e50336/attachment.bin>

From gert at greenie.muc.de  Sat Mar 28 01:14:56 2015
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 27 Mar 2015 15:14:56 +0100
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <6292251.3B6VXmd6Kx@pintsize.usersys.redhat.com>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <1725770.eLHRcz5pDi@pintsize.usersys.redhat.com>
 <20150327134513.GI21893@greenie.muc.de>
 <6292251.3B6VXmd6Kx@pintsize.usersys.redhat.com>
Message-ID: <20150327141455.GL21893@greenie.muc.de>

Hi,

On Fri, Mar 27, 2015 at 03:02:05PM +0100, Hubert Kario wrote:
> > >  * - where "support" means that either you have other people responsible
> > >  for
> > > fixing it or that you can hire other people to fix it as the need arises
> >
> > Try opening a case with HP that their ILO is broken and stupid, and they
> > will happily sell you a new machine with a less broken ILO (or "differently"
> > broken), but not do stuff like "add sane ciphers to an ILO2".  Same for
> > Cisco - of course you can buy a new machine with SSHv2, but for the old
> > one, they will do hardware replacement if it breaks, but no "new features
> > in the software"...
> 
> then vote with your wallet
> 
> as long as you keep buying broken hardware, they will keep selling broken 
> hardware

There's the thing about "primary functions" and "secondary functions".

For a server, ILO/IPMI is a secondary function, and no sane company is
going to buy something that is less good at it's primary function just
to get something better for secondary functions.  Besides, *all* the
remote management solutions are total sh*t, like "most IPMIs happily
giving anyone who asks a full list of accounts + passwords" and stuff
like that - so ILO is actually among the better ones.

For a router, things like "forwarding plane and routing protocol support"
and "user interface that the people running the network know how to
operate *and debug*" are critical elements, while "SSHv2" or "SSH with
pub key authentication" are definitely nice-to-haves, but won't make 
anyone switch vendors.

> > Yes, it would be so cool if we could just pay someone to put Linux on
> > our routing gear and give us a SSHv2 server (without breaking the functions
> > that the device is important for, like "routing").  Right.
> 
> Linux can work as a router. And nowadays most of network appliances are just 
> regular x86 PCs with nice GUI on top.

Won't particularily help if that appliance comes as a bundle, and you do
not get the keys (metaphorically speaking) to replace individual parts 
of the system...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From jwilson556 at gmail.com  Sat Mar 28 05:44:00 2015
From: jwilson556 at gmail.com (James Wilson)
Date: Fri, 27 Mar 2015 11:44:00 -0700
Subject: Multiple PAM stacks for multi-factor auth
Message-ID: <5515A4F0.40703@gmail.com>

I'd like to permit authentication by either public key followed by 
second factor, OR password followed by second factor. It seems the sshd 
configuration ought to be:

UsePam yes
PubkeyAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive 
password,keyboard-interactive

For most purposes, "UsePam yes" makes password and keyboard-interactive 
do the same thing - run the auth stack in sshd's PAM config. Thus the 
second choice in AuthenticationMethods is repeating the same policy, 
where what I want is to do a password check via pam_unix, and then run 
the 2nd-factor module. I can combine the checks in /etc/pam.d/sshd to 
make it work and then use a single "keyboard-interactive" method

auth requisite pam_unix.so
auth required pam_duo/yubico/google_authenticator/etc.so

but now the "publickey,keyboard-interactive" method requires public key, 
then password, then 2nd factor, and I haven't found a solution. I 
searched and found the Fedora encountered a similar problem and chose to 
add handling multiple PAM stacks. The discussion in 
http://fedoraproject.org/wiki/Features/MultiplePAMStacksInGDM is 
informative. Can OpenSSH add a way to run different rule sets in the 
syntax of AuthenticationMethods to make these configurations possible?

From imorgan at nas.nasa.gov  Sat Mar 28 08:43:45 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 27 Mar 2015 14:43:45 -0700
Subject: Multiple PAM stacks for multi-factor auth
In-Reply-To: <5515A4F0.40703@gmail.com>
References: <5515A4F0.40703@gmail.com>
Message-ID: <20150327214345.GB6009@linux124.nas.nasa.gov>

On Fri, Mar 27, 2015 at 11:44:00 -0700, James Wilson wrote:
> I'd like to permit authentication by either public key followed by
> second factor, OR password followed by second factor. It seems the
> sshd configuration ought to be:
> 
> UsePam yes
> PubkeyAuthentication yes
> PasswordAuthentication yes
> ChallengeResponseAuthentication yes
> AuthenticationMethods publickey,keyboard-interactive
> password,keyboard-interactive
> 
> For most purposes, "UsePam yes" makes password and
> keyboard-interactive do the same thing - run the auth stack in
> sshd's PAM config. Thus the second choice in AuthenticationMethods
> is repeating the same policy, where what I want is to do a password
> check via pam_unix, and then run the 2nd-factor module. I can
> combine the checks in /etc/pam.d/sshd to make it work and then use a
> single "keyboard-interactive" method
> 
> auth requisite pam_unix.so
> auth required pam_duo/yubico/google_authenticator/etc.so
> 
> but now the "publickey,keyboard-interactive" method requires public
> key, then password, then 2nd factor, and I haven't found a solution.
> I searched and found the Fedora encountered a similar problem and
> chose to add handling multiple PAM stacks. The discussion in
> http://fedoraproject.org/wiki/Features/MultiplePAMStacksInGDM is
> informative. Can OpenSSH add a way to run different rule sets in the
> syntax of AuthenticationMethods to make these configurations
> possible?

There have been some discussions about adding a PAMServiceName option
that would support a macro that is expanded to the authentication
method, but I'm not sure what the status is of any such patches.

Currently, sshd uses the basename of the sshd executable as the PAM
service name, so it is possible to (somewhat) simulate what you desire
by having two instances of sshd running; one using a renamed executable.
This has the disadvantage of requiring users to connect to a different
port or address depending upon how they wish to authenticate, but
otherwise will work.

There might be a way of getting this to work using z single instance
under very specific circumstances, but I don't know if what I'm about to
describe will actually work. If you are still using MD5 password hashes
and build sshd with md5 password support enabled, you could then avoid
PAM for password authentication. I'm assuming that you would need to set
UsePAM to "no," and you might need to specify pam as the subtype for
keyboard-interactive in the AuthenticationMethods line.

I haven't had an opportunity to try such a configuration, so I give not
guarantee as to whether it would work.

Extending the AuthenticationMethods syntax to support specifying the
service nzme for the PAM subtype might be interesting. I had not thought
of that before. I'm not sure if that apporach has any advantages over
the PAMServicename approach. The complication with the PAMServiceName
apporach is the expectation that the alternative PAM stacks would also
be used for the account stap, but an argument could be made for just
procesing the auth portion if the AuthenticationMethods subtype
approach were taken. So, it might be simplier, but might not be suitable
for all purposes.

-- 
Iain Morgan

From hanno at hboeck.de  Sun Mar 29 23:15:07 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Sun, 29 Mar 2015 14:15:07 +0200
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
Message-ID: <20150329141507.713c6e3b@pc1.fritz.box>

Hi,

When ssh accesses a config file that contains a zero byte it'll expose
a stack overflow. This can only be seen with valgrind or with compiling
ssh with address sanitizer. I'll attach the address sanitizer and
valgrind output.

Reproduce:
dd if=/dev/zero of=zero bs=1 count=1
valgrind -q ssh -F zero x

This was found while fuzzing ssh with american fuzzy lop.

(Please CC me on replies, I'm not subscribed to the list.)

cu,
-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssh-stackoverflow-asan.txt.gz
Type: application/gzip
Size: 958 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150329/44e47c50/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssh-stackoverflow-valgrind.txt.gz
Type: application/gzip
Size: 339 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150329/44e47c50/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150329/44e47c50/attachment-0005.bin>

From djm at mindrot.org  Mon Mar 30 09:19:02 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <20150329141507.713c6e3b@pc1.fritz.box>
References: <20150329141507.713c6e3b@pc1.fritz.box>
Message-ID: <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>

Thanks,

What version of OpenSSH is this?

Also, when reporting fuzzer-derived problems it really helps to include
the test-case.

-d

On Sun, 29 Mar 2015, Hanno B?ck wrote:

> Hi,
> 
> When ssh accesses a config file that contains a zero byte it'll expose
> a stack overflow. This can only be seen with valgrind or with compiling
> ssh with address sanitizer. I'll attach the address sanitizer and
> valgrind output.
> 
> Reproduce:
> dd if=/dev/zero of=zero bs=1 count=1
> valgrind -q ssh -F zero x
> 
> This was found while fuzzing ssh with american fuzzy lop.
> 
> (Please CC me on replies, I'm not subscribed to the list.)
> 
> cu,
> -- 
> Hanno B?ck
> http://hboeck.de/
> 
> mail/jabber: hanno at hboeck.de
> GPG: BBB51E42
> 

From hanno at hboeck.de  Mon Mar 30 09:36:02 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Mon, 30 Mar 2015 00:36:02 +0200
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
Message-ID: <20150330003602.0288da8d@pc1.fritz.box>

On Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
Damien Miller <djm at mindrot.org> wrote:

> What version of OpenSSH is this?

6.8 portable on Linux.

> Also, when reporting fuzzer-derived problems it really helps to
> include the test-case.

The "test case" is a one byte file containing a zero byte. But here it
is :-)

-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150330/9bfa2215/attachment.bin>

From djm at mindrot.org  Mon Mar 30 10:17:06 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 30 Mar 2015 10:17:06 +1100 (AEDT)
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <20150330003602.0288da8d@pc1.fritz.box>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
Message-ID: <alpine.BSO.2.11.1503301016210.8533@natsu.mindrot.org>

On Mon, 30 Mar 2015, Hanno B?ck wrote:

> On Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
> Damien Miller <djm at mindrot.org> wrote:
> 
> > What version of OpenSSH is this?
> 
> 6.8 portable on Linux.

That's strange - the line numbers in the valgrind stack trace don't
match. E.g.

==5578==    at 0x4C2CFCA: __GI_strchr (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5578==    by 0x117B6B: process_config_line (readconf.c:785)
==5578==    by 0x119DED: read_config_file (readconf.c:1633)

> > Also, when reporting fuzzer-derived problems it really helps to
> > include the test-case.
> 
> The "test case" is a one byte file containing a zero byte. But here it
> is :-)

Ok, I'll see if I can reproduce.

-d

From nkadel at gmail.com  Mon Mar 30 10:31:14 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 29 Mar 2015 19:31:14 -0400
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <20150330003602.0288da8d@pc1.fritz.box>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
Message-ID: <CAOCN9rwVueVxmO-mrktPwXbCUoh2R-+6keGpgbNizMW5uww3VQ@mail.gmail.com>

On Sun, Mar 29, 2015 at 6:36 PM, Hanno B?ck <hanno at hboeck.de> wrote:
> On Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
> Damien Miller <djm at mindrot.org> wrote:
>
>> What version of OpenSSH is this?
>
> 6.8 portable on Linux.

There are a *lot* of Linux flavors. Which one?

>> Also, when reporting fuzzer-derived problems it really helps to
>> include the test-case.
>
> The "test case" is a one byte file containing a zero byte. But here it
> is :-)
>
> --
> Hanno B?ck
> http://hboeck.de/
>
> mail/jabber: hanno at hboeck.de
> GPG: BBB51E42
>
> _______________________________________________
> 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  Mon Mar 30 10:34:52 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 30 Mar 2015 10:34:52 +1100 (AEDT)
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <CAOCN9rwVueVxmO-mrktPwXbCUoh2R-+6keGpgbNizMW5uww3VQ@mail.gmail.com>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
 <CAOCN9rwVueVxmO-mrktPwXbCUoh2R-+6keGpgbNizMW5uww3VQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503301034140.8533@natsu.mindrot.org>

On Sun, 29 Mar 2015, Nico Kadel-Garcia wrote:

> On Sun, Mar 29, 2015 at 6:36 PM, Hanno B?ck <hanno at hboeck.de> wrote:
> > On Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
> > Damien Miller <djm at mindrot.org> wrote:
> >
> >> What version of OpenSSH is this?
> >
> > 6.8 portable on Linux.
> 
> There are a *lot* of Linux flavors. Which one?

That doesn't matter much if he's using pristine sources.

-d

From djm at mindrot.org  Mon Mar 30 10:43:18 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 30 Mar 2015 10:43:18 +1100 (AEDT)
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <alpine.BSO.2.11.1503301016210.8533@natsu.mindrot.org>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
 <alpine.BSO.2.11.1503301016210.8533@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1503301040410.8533@natsu.mindrot.org>

On Mon, 30 Mar 2015, Damien Miller wrote:

> On Mon, 30 Mar 2015, Hanno B?ck wrote:
> 
> > On Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
> > Damien Miller <djm at mindrot.org> wrote:
> > 
> > > What version of OpenSSH is this?
> > 
> > 6.8 portable on Linux.
> 
> That's strange - the line numbers in the valgrind stack trace don't
> match. E.g.
> 
> ==5578==    at 0x4C2CFCA: __GI_strchr (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==5578==    by 0x117B6B: process_config_line (readconf.c:785)
> ==5578==    by 0x119DED: read_config_file (readconf.c:1633)

reproduced; the line numbers were wrong.

diff --git a/readconf.c b/readconf.c
index 42a2961..5130407 100644
--- a/readconf.c
+++ b/readconf.c
@@ -763,7 +763,9 @@ process_config_line(Options *options, struct passwd *pw, const char *host,
 	}
 
 	/* Strip trailing whitespace */
-	for (len = strlen(line) - 1; len > 0; len--) {
+	if ((len = strlen(line)) == 0)
+		return 0;
+	for (len--; len > 0; len--) {
 		if (strchr(WHITESPACE, line[len]) == NULL)
 			break;
 		line[len] = '\0';

From nkadel at gmail.com  Mon Mar 30 10:47:49 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 29 Mar 2015 19:47:49 -0400
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <alpine.BSO.2.11.1503301034140.8533@natsu.mindrot.org>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
 <CAOCN9rwVueVxmO-mrktPwXbCUoh2R-+6keGpgbNizMW5uww3VQ@mail.gmail.com>
 <alpine.BSO.2.11.1503301034140.8533@natsu.mindrot.org>
Message-ID: <CAOCN9rze=i6UKdGqR8sKV7kaHCc7N1pHqnkLRwcTXzt_e9y3vg@mail.gmail.com>

On Sun, Mar 29, 2015 at 7:34 PM, Damien Miller <djm at mindrot.org> wrote:
> On Sun, 29 Mar 2015, Nico Kadel-Garcia wrote:
>
>> On Sun, Mar 29, 2015 at 6:36 PM, Hanno B?ck <hanno at hboeck.de> wrote:
>> > On Mon, 30 Mar 2015 09:19:02 +1100 (AEDT)
>> > Damien Miller <djm at mindrot.org> wrote:
>> >
>> >> What version of OpenSSH is this?
>> >
>> > 6.8 portable on Linux.
>>
>> There are a *lot* of Linux flavors. Which one?
>
> That doesn't matter much if he's using pristine sources.
>
> -d

Diferent compiler, different glibc, different kernel, different
enabled compile time options, different configuration of SELinux can
all provide fascinating distinctions in behavior of the most
"pristine" of software. So it's a reasonable question.

From djm at mindrot.org  Mon Mar 30 10:57:06 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 30 Mar 2015 10:57:06 +1100 (AEDT)
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <CAOCN9rze=i6UKdGqR8sKV7kaHCc7N1pHqnkLRwcTXzt_e9y3vg@mail.gmail.com>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
 <CAOCN9rwVueVxmO-mrktPwXbCUoh2R-+6keGpgbNizMW5uww3VQ@mail.gmail.com>
 <alpine.BSO.2.11.1503301034140.8533@natsu.mindrot.org>
 <CAOCN9rze=i6UKdGqR8sKV7kaHCc7N1pHqnkLRwcTXzt_e9y3vg@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1503301055550.8533@natsu.mindrot.org>

On Sun, 29 Mar 2015, Nico Kadel-Garcia wrote:

> Diferent compiler, different glibc, different kernel, different
> enabled compile time options, different configuration of SELinux can
> all provide fascinating distinctions in behavior of the most
> "pristine" of software. So it's a reasonable question.

In this case it doesn't matter; none of these affect config parsing which
is where the bug was.

From hanno at hboeck.de  Mon Mar 30 11:17:48 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Mon, 30 Mar 2015 02:17:48 +0200
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <alpine.BSO.2.11.1503301040410.8533@natsu.mindrot.org>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
 <alpine.BSO.2.11.1503301016210.8533@natsu.mindrot.org>
 <alpine.BSO.2.11.1503301040410.8533@natsu.mindrot.org>
Message-ID: <20150330021748.1e2911fb@pc1.fritz.box>

On Mon, 30 Mar 2015 10:43:18 +1100 (AEDT)
Damien Miller <djm at mindrot.org> wrote:

> reproduced; the line numbers were wrong.

Sorry for the line numbers, should've thought of that. I used the
standard Gentoo package and it seems it does patching on that file.

I can confirm your patch fixes the issue, thanks. Will now run another
fuzzing job with the patch applied, will inform you if it finds
anything.

-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150330/b5429a57/attachment-0001.bin>

From djm at mindrot.org  Mon Mar 30 11:30:56 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 30 Mar 2015 11:30:56 +1100 (AEDT)
Subject: Invalid memory access / read stack overflow when reading config
 with zero bytes
In-Reply-To: <20150330021748.1e2911fb@pc1.fritz.box>
References: <20150329141507.713c6e3b@pc1.fritz.box>
 <alpine.BSO.2.11.1503300918180.8533@natsu.mindrot.org>
 <20150330003602.0288da8d@pc1.fritz.box>
 <alpine.BSO.2.11.1503301016210.8533@natsu.mindrot.org>
 <alpine.BSO.2.11.1503301040410.8533@natsu.mindrot.org>
 <20150330021748.1e2911fb@pc1.fritz.box>
Message-ID: <alpine.BSO.2.11.1503301127060.8533@natsu.mindrot.org>

On Mon, 30 Mar 2015, Hanno B?ck wrote:

> On Mon, 30 Mar 2015 10:43:18 +1100 (AEDT)
> Damien Miller <djm at mindrot.org> wrote:
> 
> > reproduced; the line numbers were wrong.
> 
> Sorry for the line numbers, should've thought of that. I used the
> standard Gentoo package and it seems it does patching on that file.
> 
> I can confirm your patch fixes the issue, thanks. Will now run another
> fuzzing job with the patch applied, will inform you if it finds
> anything.

Thanks - we'll certainly fix bugs in config parsing, but they aren't
that interesting from a security perspective. Someone who can write
to ~/.ssh/config already has arbitrary code execution via ProxyCommand,
etc.

authorized_keys is a good thing to fuzz if you can set up a good test
enviornment. I've spent about a CPU-month fuzzing key parsing and KRLs,
so I have some confidence that they are clean.

cf. https://anongit.mindrot.org/openssh-fuzz-cases.git/

-d

From hkario at redhat.com  Tue Mar 31 02:13:17 2015
From: hkario at redhat.com (Hubert Kario)
Date: Mon, 30 Mar 2015 17:13:17 +0200
Subject: FYI: SSH1 now disabled at compile-time by default
In-Reply-To: <20150327141455.GL21893@greenie.muc.de>
References: <alpine.BSO.2.11.1503251024500.21104@natsu.mindrot.org>
 <6292251.3B6VXmd6Kx@pintsize.usersys.redhat.com>
 <20150327141455.GL21893@greenie.muc.de>
Message-ID: <3213854.jW1rAczgVm@pintsize.usersys.redhat.com>

On Friday 27 March 2015 15:14:56 Gert Doering wrote:
> Hi,
> 
> On Fri, Mar 27, 2015 at 03:02:05PM +0100, Hubert Kario wrote:
> > > >  * - where "support" means that either you have other people
> > > >  responsible
> > > >  for
> > > > 
> > > > fixing it or that you can hire other people to fix it as the need
> > > > arises
> > > 
> > > Try opening a case with HP that their ILO is broken and stupid, and they
> > > will happily sell you a new machine with a less broken ILO (or
> > > "differently" broken), but not do stuff like "add sane ciphers to an
> > > ILO2".  Same for Cisco - of course you can buy a new machine with
> > > SSHv2, but for the old one, they will do hardware replacement if it
> > > breaks, but no "new features in the software"...
> > 
> > then vote with your wallet
> > 
> > as long as you keep buying broken hardware, they will keep selling broken
> > hardware
> 
> There's the thing about "primary functions" and "secondary functions".
> 
> For a server, ILO/IPMI is a secondary function, and no sane company is
> going to buy something that is less good at it's primary function just
> to get something better for secondary functions.  Besides, *all* the
> remote management solutions are total sh*t, like "most IPMIs happily
> giving anyone who asks a full list of accounts + passwords" and stuff
> like that - so ILO is actually among the better ones.
> 
> For a router, things like "forwarding plane and routing protocol support"
> and "user interface that the people running the network know how to
> operate *and debug*" are critical elements, while "SSHv2" or "SSH with
> pub key authentication" are definitely nice-to-haves, but won't make
> anyone switch vendors.

That's true, unless the servers and routers were planned to be administered 
remotely or using automated scripting from day 1...
-- 
Regards,
Hubert Kario

From calderon.thomas at gmail.com  Tue Mar 31 20:23:20 2015
From: calderon.thomas at gmail.com (Thomas Calderon)
Date: Tue, 31 Mar 2015 11:23:20 +0200
Subject: Wanted: smartcard with ECDSA support
Message-ID: <CA+1ewKbWmecJxGRhopnQ0x8C2T=Ebue==9kjHBfgXOREfyowsQ@mail.gmail.com>

Hi list,

I have no idea if Damien Miller had the time to work on that.

I have an initial patch to authenticate using PKCS#11 and ECDSA keys.
This requires OpenSSL 1.0.2, prior OpenSSL versions do not expose the
required interfaces to override the signature function pointer for ECDSA.
The only limitation is that the OpenSSL API misses some cleanup function
(finish, for instance), hence I have yet to find a way to properly free the
PKCS#11 resources.

Is this a contribution you might be interested in ?


Cheers,

Thomas Calderon