From me at halfdog.net Sun Dec 4 02:58:53 2016 From: me at halfdog.net (halfdog) Date: Sat, 03 Dec 2016 15:58:53 +0000 Subject: Extracting ephemeral keys for session decryption Message-ID: <201612031559.uB3Fxg6j035774@newmailhub.uq.edu.au> Dear list members, To decrypt SSH sessions, especially with PFS, the ephemeral keys would be needed. I want to create a demo to show how this would be working. I did a search but did not find material good enough to start working on it immediately. Are there any documents known, that describe how to proceed? I do not care about the method: recompiling SSH, ptrace, kernel module would be all fine to do it. Without such information already available, where would be the best position to tap in? For v2 PFS protocols key extraction is a must, but of course it would be nice if same method could be applied in general to eliminate the need to know at least server or client private key. Is there an intersection in the code path of DH/non-DH and perhaps v1/v2 session key generation? Would it be sufficient to tap the key once and then follow only the stream or would SSH go though full key renegotiation after some while, thus repeated tapping is required? I think the output of this could be a nice thing to learn from, also for others. Therefore any help with the key extraction part would be appreciated. hd PS: If demos are not yet available, everyone wanting to participate in creating a demo is welcome! Intended output is blog post. No companies, universities, military and no money involved! From david.michael at coreos.com Wed Dec 7 13:19:48 2016 From: david.michael at coreos.com (David Michael) Date: Tue, 06 Dec 2016 18:19:48 -0800 Subject: [PATCH] Find a host-prefixed krb5-config when cross-compiling Message-ID: <87shq032gr.fsf@coreos.com> --- Hi, I've encountered build failures when compiling with a different --host triplet. The krb5-config command would use /usr/bin/krb5-config instead of the host-prefixed version for that target. Using AC_PATH_TOOL in configure.ac addresses this. Can this change be applied? Thanks. David configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 88c4633..4d9382c 100644 --- a/configure.ac +++ b/configure.ac @@ -4151,7 +4151,7 @@ AC_ARG_WITH([kerberos5], AC_DEFINE([KRB5], [1], [Define if you want Kerberos 5 support]) KRB5_MSG="yes" - AC_PATH_PROG([KRB5CONF], [krb5-config], + AC_PATH_TOOL([KRB5CONF], [krb5-config], [$KRB5ROOT/bin/krb5-config], [$KRB5ROOT/bin:$PATH]) if test -x $KRB5CONF ; then -- 2.7.4 From reubenhwk at gmail.com Thu Dec 8 12:53:02 2016 From: reubenhwk at gmail.com (Reuben Hawkins) Date: Wed, 7 Dec 2016 17:53:02 -0800 Subject: [PATCH] don't always emit '.ssh' create error Message-ID: Hopefully gmail won't mangle the attachment (gmail seems to hate patches....nonetheless...) SSH is used to automate tasks on remote hosts. There are often special user account created for these tasks. Many of those user accounts are locked down for security. Some of those users' home path is '/dev/null'. When this is the case, ssh automated tasks clutter up the logfiles with... Could not create directory '/dev/null/.ssh'. ...this change checks that the user's home directory is actually a directory and that it is writable by that user before attempting to create the '.ssh' directory. This prevents the error. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-don-t-always-emit-.ssh-create-error.patch Type: text/x-patch Size: 2495 bytes Desc: not available URL: From dtucker at zip.com.au Thu Dec 8 12:58:57 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 8 Dec 2016 12:58:57 +1100 Subject: [PATCH] Find a host-prefixed krb5-config when cross-compiling In-Reply-To: <87shq032gr.fsf@coreos.com> References: <87shq032gr.fsf@coreos.com> Message-ID: On Wed, Dec 7, 2016 at 1:19 PM, David Michael wrote: > I've encountered build failures when compiling with a different --host > triplet. The krb5-config command would use /usr/bin/krb5-config instead > of the host-prefixed version for that target. Using AC_PATH_TOOL in > configure.ac addresses this. Can this change be applied? Applied, thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From harald.dunkel at aixigo.de Sat Dec 10 01:38:06 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 9 Dec 2016 15:38:06 +0100 Subject: HashKnownHosts vs @cert-authority Message-ID: Hi folks, maybe I am too blind to see, but would it be possible to avoid extra entries in known_hosts, if the remote host has a signed public key matching a @cert-authority line? Something like Host * HashKnownHosts unsigned This could help to keep the known_hosts file small and yet get all the unsigned public keys in. Just a suggestion, of course. Regards Harri From djm at mindrot.org Mon Dec 12 19:09:20 2016 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Dec 2016 19:09:20 +1100 (AEDT) Subject: HashKnownHosts vs @cert-authority In-Reply-To: References: Message-ID: On Fri, 9 Dec 2016, Harald Dunkel wrote: > Hi folks, > > maybe I am too blind to see, but would it be possible to > avoid extra entries in known_hosts, if the remote host > has a signed public key matching a @cert-authority line? > Something like > > Host * > HashKnownHosts unsigned > > This could help to keep the known_hosts file small and > yet get all the unsigned public keys in. Certificates aren't added to known_hosts when the CA is trusted, so this is pretty much already the behaviour. -d From harald.dunkel at aixigo.de Mon Dec 12 23:16:52 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Mon, 12 Dec 2016 13:16:52 +0100 Subject: HashKnownHosts vs @cert-authority In-Reply-To: References: Message-ID: <523a4eaa-61f6-c81c-62e0-923d7a6638d8@aixigo.de> On 12/12/2016 09:09 AM, Damien Miller wrote: > On Fri, 9 Dec 2016, Harald Dunkel wrote: > >> Hi folks, >> >> maybe I am too blind to see, but would it be possible to >> avoid extra entries in known_hosts, if the remote host >> has a signed public key matching a @cert-authority line? >> Something like >> >> Host * >> HashKnownHosts unsigned >> >> This could help to keep the known_hosts file small and >> yet get all the unsigned public keys in. > > Certificates aren't added to known_hosts when the CA is trusted, > so this is pretty much already the behaviour. > > -d > I'm not talking about the signed certificates, but the host keys. Sample session: % cat .ssh/known_hosts.ca @cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...5yM9EUO40GTkTDdm/tqXLr root at ca.example.com @cert-authority *.hosting.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQA...w83RVE37kLAaoGXjQ8mKp4wuUmRuxf root at dex02.hosting.example.com % ssh -o UserKnownHostsFile=${HOME}/.ssh/known_hosts.ca dpcl064 echo "hello, world" Warning: Permanently added 'dpcl064' (RSA) to the list of known hosts. hello, world % 551} cat .ssh/known_hosts.ca @cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...5yM9EUO40GTkTDdm/tqXLr root at ca.example.com @cert-authority *.hosting.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQA...w83RVE37kLAaoGXjQ8mKp4wuUmRuxf root at dex02.hosting.example.com |1|enWm+4uvYU/G0qgjuYP0TpxIk3M=|MpKwoY+HIrUJbcR4vrNH1xYxWT4= ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...I2bbm6C52Uga3TBWQ7F+xG0Wd5k1I+KMJnJ Regards Harri From mindrot at hda3.com Tue Dec 13 03:23:52 2016 From: mindrot at hda3.com (Peter Moody) Date: Mon, 12 Dec 2016 08:23:52 -0800 Subject: HashKnownHosts vs @cert-authority In-Reply-To: <523a4eaa-61f6-c81c-62e0-923d7a6638d8@aixigo.de> References: <523a4eaa-61f6-c81c-62e0-923d7a6638d8@aixigo.de> Message-ID: On Dec 12, 2016 4:17 AM, "Harald Dunkel" wrote: On 12/12/2016 09:09 AM, Damien Miller wrote: > On Fri, 9 Dec 2016, Harald Dunkel wrote: > >> Hi folks, >> >> maybe I am too blind to see, but would it be possible to >> avoid extra entries in known_hosts, if the remote host >> has a signed public key matching a @cert-authority line? >> Something like >> >> Host * >> HashKnownHosts unsigned >> >> This could help to keep the known_hosts file small and >> yet get all the unsigned public keys in. > > Certificates aren't added to known_hosts when the CA is trusted, > so this is pretty much already the behaviour. > > -d > I'm not talking about the signed certificates, but the host keys. Sample session: % cat .ssh/known_hosts.ca @cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...5yM9EUO40GTkTDdm/tqXLr root at ca.example.com @cert-authority *.hosting.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQA...w83RVE37kLAaoGXjQ8mKp4wuUmRuxf root at dex02.hosting.example.com % ssh -o UserKnownHostsFile=${HOME}/.ssh/known_hosts.ca dpcl064 echo "hello, world" Warning: Permanently added 'dpcl064' Your cert is good for *.hosting.example.com but you're connecting to dpcl064. unless your ssh_config is doing some canonicalization, your client won't accept the host cert presented since the host name doesn't match the principals listed in the ca. (RSA) to the list of known hosts. hello, world % 551} cat .ssh/known_hosts.ca @cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...5yM9EUO40GTkTDdm/tqXLr root at ca.example.com @cert-authority *.hosting.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQA...w83RVE37kLAaoGXjQ8mKp4wuUmRuxf root at dex02.hosting.example.com |1|enWm+4uvYU/G0qgjuYP0TpxIk3M=|MpKwoY+HIrUJbcR4vrNH1xYxWT4= ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...I2bbm6C52Uga3TBWQ7F+xG0Wd5k1I+KMJnJ Regards Harri _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From theonetruekenny at gmail.com Wed Dec 14 06:00:08 2016 From: theonetruekenny at gmail.com (Kenny Simpson) Date: Tue, 13 Dec 2016 14:00:08 -0500 Subject: pkcs #11/hardware support for server keys/sshd? Message-ID: Hello, Is there any support (existing or planned) for host keys/certs being managed by some hardware device (tpm,hsm,etc..) instead of a flat file? thanks, -Kenny From theonetruekenny at gmail.com Wed Dec 14 06:31:12 2016 From: theonetruekenny at gmail.com (Kenny Simpson) Date: Tue, 13 Dec 2016 14:31:12 -0500 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: References: Message-ID: I see support for client (ssh/ssh_config), but not server (sshd/sshd_config). -Kenny On Tue, Dec 13, 2016 at 2:29 PM, Alon Bar-Lev wrote: > On 13 December 2016 at 21:00, Kenny Simpson wrote: >> Hello, >> Is there any support (existing or planned) for host keys/certs being >> managed by some hardware device (tpm,hsm,etc..) instead of a flat >> file? > > man ssh > search for PKCS#11 From alon.barlev at gmail.com Wed Dec 14 06:29:41 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 13 Dec 2016 21:29:41 +0200 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: References: Message-ID: On 13 December 2016 at 21:00, Kenny Simpson wrote: > Hello, > Is there any support (existing or planned) for host keys/certs being > managed by some hardware device (tpm,hsm,etc..) instead of a flat > file? man ssh search for PKCS#11 From alon.barlev at gmail.com Wed Dec 14 06:38:25 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 13 Dec 2016 21:38:25 +0200 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: References: Message-ID: On 13 December 2016 at 21:31, Kenny Simpson wrote: > I see support for client (ssh/ssh_config), but not server (sshd/sshd_config). ok, sorry, I did not understand the question. Have you looked into HostKeyAgent at sshd_config? I've never tried this, but should work if you load PKCS#11 keys into the agent. > > -Kenny > > > On Tue, Dec 13, 2016 at 2:29 PM, Alon Bar-Lev wrote: >> On 13 December 2016 at 21:00, Kenny Simpson wrote: >>> Hello, >>> Is there any support (existing or planned) for host keys/certs being >>> managed by some hardware device (tpm,hsm,etc..) instead of a flat >>> file? >> >> man ssh >> search for PKCS#11 From theonetruekenny at gmail.com Wed Dec 14 06:47:33 2016 From: theonetruekenny at gmail.com (Kenny Simpson) Date: Tue, 13 Dec 2016 14:47:33 -0500 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: References: Message-ID: Thanks! This looks like it will do! -Kenny On Tue, Dec 13, 2016 at 2:38 PM, Alon Bar-Lev wrote: > On 13 December 2016 at 21:31, Kenny Simpson wrote: >> I see support for client (ssh/ssh_config), but not server (sshd/sshd_config). > > ok, sorry, I did not understand the question. > Have you looked into HostKeyAgent at sshd_config? > I've never tried this, but should work if you load PKCS#11 keys into the agent. > >> >> -Kenny >> >> >> On Tue, Dec 13, 2016 at 2:29 PM, Alon Bar-Lev wrote: >>> On 13 December 2016 at 21:00, Kenny Simpson wrote: >>>> Hello, >>>> Is there any support (existing or planned) for host keys/certs being >>>> managed by some hardware device (tpm,hsm,etc..) instead of a flat >>>> file? >>> >>> man ssh >>> search for PKCS#11 From uri at ll.mit.edu Wed Dec 14 06:58:23 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 13 Dec 2016 19:58:23 +0000 Subject: pkcs #11/hardware support for server keys/sshd? Message-ID: <20161213195832.18280523.60544.106538@ll.mit.edu> But would the *server* be able to use the keys on a PKCS#11 device (that does not let the private keys out)? Client does it fine, I know. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Alon Bar-Lev Sent: Tuesday, December 13, 2016 14:54 To: Kenny Simpson Cc: openssh-unix-dev at mindrot.org Subject: Re: pkcs #11/hardware support for server keys/sshd? On 13 December 2016 at 21:31, Kenny Simpson wrote: > I see support for client (ssh/ssh_config), but not server (sshd/sshd_config). ok, sorry, I did not understand the question. Have you looked into HostKeyAgent at sshd_config? I've never tried this, but should work if you load PKCS#11 keys into the agent. > > -Kenny > > > On Tue, Dec 13, 2016 at 2:29 PM, Alon Bar-Lev wrote: >> On 13 December 2016 at 21:00, Kenny Simpson wrote: >>> Hello, >>> Is there any support (existing or planned) for host keys/certs being >>> managed by some hardware device (tpm,hsm,etc..) instead of a flat >>> file? >> >> man ssh >> search for PKCS#11 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From djm at mindrot.org Wed Dec 14 11:53:32 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Dec 2016 11:53:32 +1100 (AEDT) Subject: Call for testing: OpenSSH 7.4 Message-ID: Hi, OpenSSH 7.4 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/ or via a mirror at Github: https://github.com/openssh/openssh-portable 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. Potentially-incompatible changes ================================ This release includes a number of changes that may affect existing configurations: * This release removes server support for the SSH v.1 protocol. * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit block ciphers are not safe in 2016 and we don't want to wait until attacks like SWEET32 are extended to SSH. As 3des-cbc was the only mandatory cipher in the SSH RFCs, this may cause problems connecting to older devices using the default configuration, but it's highly likely that such devices already need explicit configuration for key exchange and hostkey algorithms already anyway. * sshd(8): Remove support for pre-authentication compression. Doing compression early in the protocol probably seemed reasonable in the 1990s, but today it's clearly a bad idea in terms of both cryptography (cf. multiple compression oracle attacks in TLS) and attack surface. Pre-auth compression support has been disabled by default for >10 years. Support remains in the client. * ssh-agent will refuse to load PKCS#11 modules outside a whitelist of trusted paths by default. The path whitelist may be specified at run-time. * sshd(8): When a forced-command appears in both a certificate and an authorized keys/principals command= restriction, sshd will now refuse to accept the certificate unless they are identical. The previous (documented) behaviour of having the certificate forced-command override the other could be a bit confusing and error-prone. * sshd(8): Remove the UseLogin configuration directive and support for having /bin/login manage login sessions. Changes since OpenSSH 7.3 ========================= This is primarily a bugfix release. New Features ------------ * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the version in PuTTY by Simon Tatham. This allows a multiplexing client to communicate with the master process using a subset of the SSH packet and channels protocol over a Unix-domain socket, with the main process acting as a proxy that translates channel IDs, etc. This allows multiplexing mode to run on systems that lack file- descriptor passing (used by current multiplexing code) and potentially, in conjunction with Unix-domain socket forwarding, with the client and multiplexing master process on different machines. Multiplexing proxy mode may be invoked using "ssh -O proxy ..." * sshd(8): Add a sshd_config DisableForwaring option that disables X11, agent, TCP, tunnel and Unix domain socket forwarding, as well as anything else we might implement in the future. Like the 'restrict' authorized_keys flag, this is intended to be a simple and future-proof way of restricting an account. * sshd(8), ssh(1): Support the "curve25519-sha256" key exchange method. This is identical to the currently-support method named "curve25519-sha256 at libssh.org". * sshd(8): Improve handling of SIGHUP by checking to see if sshd is already daemonised at startup and skipping the call to daemon(3) if it is. This ensures that a SIGHUP restart of sshd(8) will retain the same process-ID as the initial execution. sshd(8) will also now unlink the PidFile prior to SIGHUP restart and re-create it after a successful restart, rather than leaving a stale file in the case of a configuration error. bz#2641 * sshd(8): Allow ClientAliveInterval and ClientAliveCountMax directives to appear in sshd_config Match blocks. * sshd(8): Add %-escapes to AuthorizedPrincipalsCommand to match those supported by AuthorizedKeysCommand (key, key type, fingerprint, etc.) and a few more to provide access to the contents of the certificate being offered. * Added regression tests for string matching, address matching and string sanitisation functions. * Improved the key exchange fuzzer harness. Bugfixes -------- * ssh(1): Allow IdentityFile to successfully load and use certificates that have no corresponding bare public key. bz#2617 certificate id_rsa-cert.pub (and no id_rsa.pub). * ssh(1): Fix public key authentication when multiple authentication is in use and publickey is not just the first method attempted. bz#2642 * regress: Allow the PuTTY interop tests to run unattended. bz#2639 * ssh-agent(1), ssh(1): improve reporting when attempting to load keys from PKCS#11 tokens with fewer useless log messages and more detail in debug messages. bz#2610 * ssh(1): When tearing down ControlMaster connections, don't pollute stderr when LogLevel=quiet. * sftp(1): On ^Z wait for underlying ssh(1) to suspend before suspending sftp(1) to ensure that ssh(1) restores the terminal mode correctly if suspended during a password prompt. * ssh(1): Avoid busy-wait when ssh(1) is suspended during a password prompt. * ssh(1), sshd(8): Correctly report errors during sending of ext- info messages. * sshd(8): fix NULL-deref crash if sshd(8) received an out-of- sequence NEWKEYS message. * sshd(8): Correct list of supported signature algorithms sent in the server-sig-algs extension. bz#2547 * sshd(8): Fix sending ext_info message if privsep is disabled. * sshd(8): more strictly enforce the expected ordering of privilege separation monitor calls used for authentication and allow them only when their respective authentication methods are enabled in the configuration * sshd(8): Fix uninitialised optlen in getsockopt() call; harmless on Unix/BSD but potentially crashy on Cygwin. * Fix false positive reports caused by explicit_bzero(3) not being recognised as a memory initialiser when compiled with -fsanitize-memory. * sshd_config(5): Use 2001:db8::/32, the official IPv6 subnet for configuration examples. Portability ----------- * On environments configured with Turkish locales, fall back to the C/POSIX locale to avoid errors in configuration parsing caused by that locale's unique handling of the letters 'i' and 'I'. bz#2643 * sftp-server(8), ssh-agent(1): Deny ptrace on OS X using ptrace(PT_DENY_ATTACH, ..) * ssh(1), sshd(8): Unbreak AES-CTR ciphers on old (~0.9.8) OpenSSL. * Fix compilation for libcrypto compiled without RIPEMD160 support. * contrib: Add a gnome-ssh-askpass3 with GTK+3 support. bz#2640 * sshd(8): Improve PRNG reseeding across privilege separation and force libcrypto to obtain a high-quality seed before chroot or sandboxing. * All: Explicitly test for broken strnvis. NetBSD added an strnvis and unfortunately made it incompatible with the existing one in OpenBSD and Linux's libbsd (the former having existed for over ten years). Try to detect this mess, and assume the only safe option if we're cross compiling. 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 doctor at doctor.nl2k.ab.ca Wed Dec 14 12:09:25 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 13 Dec 2016 18:09:25 -0700 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <20161214010925.GA75127@doctor.nl2k.ab.ca> On Wed, Dec 14, 2016 at 11:53:32AM +1100, Damien Miller wrote: > Hi, > > OpenSSH 7.4 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/ or via a > mirror at Github: https://github.com/openssh/openssh-portable > > 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. Got you. Will run make tests. So far running on FreeBSD 11.0 using openssl 1.0.2 current . Trying Openssl 1.1 > > Potentially-incompatible changes > ================================ > > This release includes a number of changes that may affect existing > configurations: > > * This release removes server support for the SSH v.1 protocol. > > * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit > block ciphers are not safe in 2016 and we don't want to wait until > attacks like SWEET32 are extended to SSH. As 3des-cbc was the > only mandatory cipher in the SSH RFCs, this may cause problems > connecting to older devices using the default configuration, > but it's highly likely that such devices already need explicit > configuration for key exchange and hostkey algorithms already > anyway. > > * sshd(8): Remove support for pre-authentication compression. > Doing compression early in the protocol probably seemed reasonable > in the 1990s, but today it's clearly a bad idea in terms of both > cryptography (cf. multiple compression oracle attacks in TLS) and > attack surface. Pre-auth compression support has been disabled by > default for >10 years. Support remains in the client. > > * ssh-agent will refuse to load PKCS#11 modules outside a whitelist > of trusted paths by default. The path whitelist may be specified > at run-time. > > * sshd(8): When a forced-command appears in both a certificate and > an authorized keys/principals command= restriction, sshd will now > refuse to accept the certificate unless they are identical. > The previous (documented) behaviour of having the certificate > forced-command override the other could be a bit confusing and > error-prone. > > * sshd(8): Remove the UseLogin configuration directive and support > for having /bin/login manage login sessions. > > Changes since OpenSSH 7.3 > ========================= > > This is primarily a bugfix release. > > New Features > ------------ > > * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the > version in PuTTY by Simon Tatham. This allows a multiplexing > client to communicate with the master process using a subset of > the SSH packet and channels protocol over a Unix-domain socket, > with the main process acting as a proxy that translates channel > IDs, etc. This allows multiplexing mode to run on systems that > lack file- descriptor passing (used by current multiplexing > code) and potentially, in conjunction with Unix-domain socket > forwarding, with the client and multiplexing master process on > different machines. Multiplexing proxy mode may be invoked using > "ssh -O proxy ..." > > * sshd(8): Add a sshd_config DisableForwaring option that disables > X11, agent, TCP, tunnel and Unix domain socket forwarding, as well > as anything else we might implement in the future. Like the > 'restrict' authorized_keys flag, this is intended to be a simple > and future-proof way of restricting an account. > > * sshd(8), ssh(1): Support the "curve25519-sha256" key exchange > method. This is identical to the currently-support method named > "curve25519-sha256 at libssh.org". > > * sshd(8): Improve handling of SIGHUP by checking to see if sshd is > already daemonised at startup and skipping the call to daemon(3) > if it is. This ensures that a SIGHUP restart of sshd(8) will > retain the same process-ID as the initial execution. sshd(8) will > also now unlink the PidFile prior to SIGHUP restart and re-create > it after a successful restart, rather than leaving a stale file in > the case of a configuration error. bz#2641 > > * sshd(8): Allow ClientAliveInterval and ClientAliveCountMax > directives to appear in sshd_config Match blocks. > > * sshd(8): Add %-escapes to AuthorizedPrincipalsCommand to match > those supported by AuthorizedKeysCommand (key, key type, > fingerprint, etc.) and a few more to provide access to the > contents of the certificate being offered. > > * Added regression tests for string matching, address matching and > string sanitisation functions. > > * Improved the key exchange fuzzer harness. > > Bugfixes > -------- > > * ssh(1): Allow IdentityFile to successfully load and use > certificates that have no corresponding bare public key. bz#2617 > certificate id_rsa-cert.pub (and no id_rsa.pub). > > * ssh(1): Fix public key authentication when multiple > authentication is in use and publickey is not just the first > method attempted. bz#2642 > > * regress: Allow the PuTTY interop tests to run unattended. bz#2639 > > * ssh-agent(1), ssh(1): improve reporting when attempting to load > keys from PKCS#11 tokens with fewer useless log messages and more > detail in debug messages. bz#2610 > > * ssh(1): When tearing down ControlMaster connections, don't > pollute stderr when LogLevel=quiet. > > * sftp(1): On ^Z wait for underlying ssh(1) to suspend before > suspending sftp(1) to ensure that ssh(1) restores the terminal mode > correctly if suspended during a password prompt. > > * ssh(1): Avoid busy-wait when ssh(1) is suspended during a password > prompt. > > * ssh(1), sshd(8): Correctly report errors during sending of ext- > info messages. > > * sshd(8): fix NULL-deref crash if sshd(8) received an out-of- > sequence NEWKEYS message. > > * sshd(8): Correct list of supported signature algorithms sent in > the server-sig-algs extension. bz#2547 > > * sshd(8): Fix sending ext_info message if privsep is disabled. > > * sshd(8): more strictly enforce the expected ordering of privilege > separation monitor calls used for authentication and allow them > only when their respective authentication methods are enabled > in the configuration > > * sshd(8): Fix uninitialised optlen in getsockopt() call; harmless > on Unix/BSD but potentially crashy on Cygwin. > > * Fix false positive reports caused by explicit_bzero(3) not being > recognised as a memory initialiser when compiled with > -fsanitize-memory. > > * sshd_config(5): Use 2001:db8::/32, the official IPv6 subnet for > configuration examples. > > Portability > ----------- > > * On environments configured with Turkish locales, fall back to the > C/POSIX locale to avoid errors in configuration parsing caused by > that locale's unique handling of the letters 'i' and 'I'. bz#2643 > > * sftp-server(8), ssh-agent(1): Deny ptrace on OS X using > ptrace(PT_DENY_ATTACH, ..) > > * ssh(1), sshd(8): Unbreak AES-CTR ciphers on old (~0.9.8) OpenSSL. > > * Fix compilation for libcrypto compiled without RIPEMD160 support. > > * contrib: Add a gnome-ssh-askpass3 with GTK+3 support. bz#2640 > > * sshd(8): Improve PRNG reseeding across privilege separation and > force libcrypto to obtain a high-quality seed before chroot or > sandboxing. > > * All: Explicitly test for broken strnvis. NetBSD added an strnvis > and unfortunately made it incompatible with the existing one in > OpenBSD and Linux's libbsd (the former having existed for over ten > years). Try to detect this mess, and assume the only safe option > if we're cross compiling. > > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de > Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, > Tim Rice and Ben Lindstrom. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From djm at mindrot.org Wed Dec 14 12:12:21 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Dec 2016 12:12:21 +1100 (AEDT) Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214010925.GA75127@doctor.nl2k.ab.ca> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> Message-ID: On Tue, 13 Dec 2016, The Doctor wrote: > Got you. Will run make tests. So far running on > FreeBSD 11.0 using openssl 1.0.2 current Thanks! > Trying Openssl 1.1 Won't work - see the thread here about 6 week back... -d From doctor at doctor.nl2k.ab.ca Wed Dec 14 12:22:41 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 13 Dec 2016 18:22:41 -0700 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: <20161214010925.GA75127@doctor.nl2k.ab.ca> Message-ID: <20161214012241.GA84711@doctor.nl2k.ab.ca> On Wed, Dec 14, 2016 at 12:12:21PM +1100, Damien Miller wrote: > On Tue, 13 Dec 2016, The Doctor wrote: > > > Got you. Will run make tests. So far running on > > FreeBSD 11.0 using openssl 1.0.2 current > > Thanks! Point of concern run test sftp-perm.sh ... sftp permissions: read-only upload sftp permissions: read-only setstat 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 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 ok sftp permissions run test reconfigure.sh ... ok simple connect after reconfigure run test dynamic-forward.sh ... ok dynamic forwarding run test forwarding.sh ... failed copy of /bin/ls cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy corrupted copy of /bin/ls Exit request sent. failed local and remote forwarding *** Error code 1 Stop. make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress *** Error code 1 Stop. make: stopped in /usr/source/openssh-SNAP-20161214 > > > Trying Openssl 1.1 > > Won't work - see the thread here about 6 week back... > :-( What about libressl? > -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 Merry Christmas 2016 and Happy New Year 2017 From doctor at doctor.nl2k.ab.ca Wed Dec 14 12:30:22 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 13 Dec 2016 18:30:22 -0700 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214012241.GA84711@doctor.nl2k.ab.ca> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> Message-ID: <20161214013022.GA85933@doctor.nl2k.ab.ca> On Tue, Dec 13, 2016 at 06:22:41PM -0700, The Doctor wrote: > On Wed, Dec 14, 2016 at 12:12:21PM +1100, Damien Miller wrote: > > On Tue, 13 Dec 2016, The Doctor wrote: > > > > > Got you. Will run make tests. So far running on > > > FreeBSD 11.0 using openssl 1.0.2 current > > > > Thanks! > > Point of concern > > run test sftp-perm.sh ... > sftp permissions: read-only upload > sftp permissions: read-only setstat > 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 > 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 > ok sftp permissions > run test reconfigure.sh ... > ok simple connect after reconfigure > run test dynamic-forward.sh ... > ok dynamic forwarding > run test forwarding.sh ... > failed copy of /bin/ls > cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy > corrupted copy of /bin/ls > Exit request sent. > failed local and remote forwarding > *** Error code 1 > > Stop. > make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress > *** Error code 1 > > Stop. > make: stopped in /usr/source/openssh-SNAP-20161214 > Further test using openssl with the current FreeBSD 11.0 patches run test multiplex.sh ... test connection multiplexing: envpass test connection multiplexing: transfer test connection multiplexing: forward cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy ssh: corrupted copy of /usr/source/openssh-SNAP-20161214/regress/data test connection multiplexing: status 0 test connection multiplexing: status 1 test connection multiplexing: status 4 test connection multiplexing: status 5 test connection multiplexing: status 44 test connection multiplexing: cmd check test connection multiplexing: cmd forward local (TCP) test connection multiplexing: cmd forward remote (TCP) test connection multiplexing: cmd forward local (UNIX) test connection multiplexing: cmd forward remote (UNIX) request remote forward failed connect to remote forwarded path failed test connection multiplexing: cmd exit test connection multiplexing: cmd stop failed connection multiplexing *** Error code 1 (continuing) `tests' not remade because of errors. all tests passed > > > > > > Trying Openssl 1.1 > > > > Won't work - see the thread here about 6 week back... > > > > :-( What about libressl? > > > -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 > Merry Christmas 2016 and Happy New Year 2017 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From djm at mindrot.org Wed Dec 14 12:54:01 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Dec 2016 12:54:01 +1100 (AEDT) Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214013022.GA85933@doctor.nl2k.ab.ca> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> <20161214013022.GA85933@doctor.nl2k.ab.ca> Message-ID: On Tue, 13 Dec 2016, The Doctor wrote: > > Point of concern ... > > run test forwarding.sh ... Could you please rerun the test with tracing on? That will show the failed test: make tests LTESTS=forwarding TEST_SSH_TRACE=yes SKIP_UNIT=1 There might also be some clues in regress/failed* -d From mindrot at hda3.com Wed Dec 14 12:55:53 2016 From: mindrot at hda3.com (Peter Moody) Date: Tue, 13 Dec 2016 17:55:53 -0800 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: Hey Damien, my special snowflake cert tests seem to work fine on osx sierra (OpenSSH_7.3p1-snap20161214, OpenSSL 1.0.2j 26 Sep 2016). thanks! On Tue, Dec 13, 2016 at 4:53 PM, Damien Miller wrote: > Hi, > > OpenSSH 7.4 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/ or via a > mirror at Github: https://github.com/openssh/openssh-portable > > 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. > > Potentially-incompatible changes > ================================ > > This release includes a number of changes that may affect existing > configurations: > > * This release removes server support for the SSH v.1 protocol. > > * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit > block ciphers are not safe in 2016 and we don't want to wait until > attacks like SWEET32 are extended to SSH. As 3des-cbc was the > only mandatory cipher in the SSH RFCs, this may cause problems > connecting to older devices using the default configuration, > but it's highly likely that such devices already need explicit > configuration for key exchange and hostkey algorithms already > anyway. > > * sshd(8): Remove support for pre-authentication compression. > Doing compression early in the protocol probably seemed reasonable > in the 1990s, but today it's clearly a bad idea in terms of both > cryptography (cf. multiple compression oracle attacks in TLS) and > attack surface. Pre-auth compression support has been disabled by > default for >10 years. Support remains in the client. > > * ssh-agent will refuse to load PKCS#11 modules outside a whitelist > of trusted paths by default. The path whitelist may be specified > at run-time. > > * sshd(8): When a forced-command appears in both a certificate and > an authorized keys/principals command= restriction, sshd will now > refuse to accept the certificate unless they are identical. > The previous (documented) behaviour of having the certificate > forced-command override the other could be a bit confusing and > error-prone. > > * sshd(8): Remove the UseLogin configuration directive and support > for having /bin/login manage login sessions. > > Changes since OpenSSH 7.3 > ========================= > > This is primarily a bugfix release. > > New Features > ------------ > > * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the > version in PuTTY by Simon Tatham. This allows a multiplexing > client to communicate with the master process using a subset of > the SSH packet and channels protocol over a Unix-domain socket, > with the main process acting as a proxy that translates channel > IDs, etc. This allows multiplexing mode to run on systems that > lack file- descriptor passing (used by current multiplexing > code) and potentially, in conjunction with Unix-domain socket > forwarding, with the client and multiplexing master process on > different machines. Multiplexing proxy mode may be invoked using > "ssh -O proxy ..." > > * sshd(8): Add a sshd_config DisableForwaring option that disables > X11, agent, TCP, tunnel and Unix domain socket forwarding, as well > as anything else we might implement in the future. Like the > 'restrict' authorized_keys flag, this is intended to be a simple > and future-proof way of restricting an account. > > * sshd(8), ssh(1): Support the "curve25519-sha256" key exchange > method. This is identical to the currently-support method named > "curve25519-sha256 at libssh.org". > > * sshd(8): Improve handling of SIGHUP by checking to see if sshd is > already daemonised at startup and skipping the call to daemon(3) > if it is. This ensures that a SIGHUP restart of sshd(8) will > retain the same process-ID as the initial execution. sshd(8) will > also now unlink the PidFile prior to SIGHUP restart and re-create > it after a successful restart, rather than leaving a stale file in > the case of a configuration error. bz#2641 > > * sshd(8): Allow ClientAliveInterval and ClientAliveCountMax > directives to appear in sshd_config Match blocks. > > * sshd(8): Add %-escapes to AuthorizedPrincipalsCommand to match > those supported by AuthorizedKeysCommand (key, key type, > fingerprint, etc.) and a few more to provide access to the > contents of the certificate being offered. > > * Added regression tests for string matching, address matching and > string sanitisation functions. > > * Improved the key exchange fuzzer harness. > > Bugfixes > -------- > > * ssh(1): Allow IdentityFile to successfully load and use > certificates that have no corresponding bare public key. bz#2617 > certificate id_rsa-cert.pub (and no id_rsa.pub). > > * ssh(1): Fix public key authentication when multiple > authentication is in use and publickey is not just the first > method attempted. bz#2642 > > * regress: Allow the PuTTY interop tests to run unattended. bz#2639 > > * ssh-agent(1), ssh(1): improve reporting when attempting to load > keys from PKCS#11 tokens with fewer useless log messages and more > detail in debug messages. bz#2610 > > * ssh(1): When tearing down ControlMaster connections, don't > pollute stderr when LogLevel=quiet. > > * sftp(1): On ^Z wait for underlying ssh(1) to suspend before > suspending sftp(1) to ensure that ssh(1) restores the terminal mode > correctly if suspended during a password prompt. > > * ssh(1): Avoid busy-wait when ssh(1) is suspended during a password > prompt. > > * ssh(1), sshd(8): Correctly report errors during sending of ext- > info messages. > > * sshd(8): fix NULL-deref crash if sshd(8) received an out-of- > sequence NEWKEYS message. > > * sshd(8): Correct list of supported signature algorithms sent in > the server-sig-algs extension. bz#2547 > > * sshd(8): Fix sending ext_info message if privsep is disabled. > > * sshd(8): more strictly enforce the expected ordering of privilege > separation monitor calls used for authentication and allow them > only when their respective authentication methods are enabled > in the configuration > > * sshd(8): Fix uninitialised optlen in getsockopt() call; harmless > on Unix/BSD but potentially crashy on Cygwin. > > * Fix false positive reports caused by explicit_bzero(3) not being > recognised as a memory initialiser when compiled with > -fsanitize-memory. > > * sshd_config(5): Use 2001:db8::/32, the official IPv6 subnet for > configuration examples. > > Portability > ----------- > > * On environments configured with Turkish locales, fall back to the > C/POSIX locale to avoid errors in configuration parsing caused by > that locale's unique handling of the letters 'i' and 'I'. bz#2643 > > * sftp-server(8), ssh-agent(1): Deny ptrace on OS X using > ptrace(PT_DENY_ATTACH, ..) > > * ssh(1), sshd(8): Unbreak AES-CTR ciphers on old (~0.9.8) OpenSSL. > > * Fix compilation for libcrypto compiled without RIPEMD160 support. > > * contrib: Add a gnome-ssh-askpass3 with GTK+3 support. bz#2640 > > * sshd(8): Improve PRNG reseeding across privilege separation and > force libcrypto to obtain a high-quality seed before chroot or > sandboxing. > > * All: Explicitly test for broken strnvis. NetBSD added an strnvis > and unfortunately made it incompatible with the existing one in > OpenBSD and Linux's libbsd (the former having existed for over ten > years). Try to detect this mess, and assume the only safe option > if we're cross compiling. > > > 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 From dtucker at zip.com.au Wed Dec 14 12:55:57 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 14 Dec 2016 12:55:57 +1100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214012241.GA84711@doctor.nl2k.ab.ca> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> Message-ID: On Wed, Dec 14, 2016 at 12:22 PM, The Doctor wrote: [tests] > Stop. > make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress > *** Error code 1 There should be some files "failed-ssh.log" and "failed-sshd.log" in the regress directory, which are the debug logs from the command invocations that failed. They might give you some idea what went wrong. [...] > :-( What about libressl? Should work, we test against versions 2.1.8, 2.2.4, 2.2.8, 2.3.1, 2.3.5, 2.4.0 (although the tests are currently lagging due to hardware problems on the test box). Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Wed Dec 14 12:59:23 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Dec 2016 12:59:23 +1100 (AEDT) Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: On Tue, 13 Dec 2016, Peter Moody wrote: > Hey Damien, my special snowflake cert tests seem to work fine on osx sierra > (OpenSSH_7.3p1-snap20161214, OpenSSL 1.0.2j 26 Sep 2016). Thanks - all certificates are special snowflakes :) From doctor at doctor.nl2k.ab.ca Wed Dec 14 15:51:23 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 13 Dec 2016 21:51:23 -0700 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> <20161214013022.GA85933@doctor.nl2k.ab.ca> Message-ID: <20161214045123.GA26640@doctor.nl2k.ab.ca> On Wed, Dec 14, 2016 at 12:54:01PM +1100, Damien Miller wrote: > On Tue, 13 Dec 2016, The Doctor wrote: > > > > Point of concern > > ... > > > > run test forwarding.sh ... > > Could you please rerun the test with tracing on? That will show the > failed test: > > make tests LTESTS=forwarding TEST_SSH_TRACE=yes SKIP_UNIT=1 make tests LTESTS=forwarding TEST_SSH_TRACE=yes SKIP_UNIT=1 [ -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 [ -d `pwd`/regress/unittests/match ] || mkdir -p `pwd`/regress/unittests/match [ -d `pwd`/regress/unittests/utf8 ] || mkdir -p `pwd`/regress/unittests/utf8 [ -d `pwd`/regress/misc/kexfuzz ] || mkdir -p `pwd`/regress/misc/kexfuzz [ -f `pwd`/regress/Makefile ] || ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile (cd openbsd-compat && make) 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_UTF8="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="AJRX" TEST_MALLOC_OPTIONS="AJRX" 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_UTF8="${TEST_SSH_UTF8}" TEST_SSH_ECC="${TEST_SSH_ECC}" TEST_SHELL="sh" EXEEXT="" tests && echo all tests passed test "x" = "x" || mkdir -p /usr/source/openssh-SNAP-20161214/regress//valgrind-out set -e ; if test -z "1" ; then V="" ; test "x" = "x" || V=/usr/source/openssh-SNAP-20161214/regress/valgrind-unit.sh ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/sshbuf/test_sshbuf ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/sshkey/test_sshkey -d /usr/source/openssh-SNAP-20161214/regress/unittests/sshkey/testdata ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/bitmap/test_bitmap ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/kex/test_kex ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/hostkeys/test_hostkeys -d /usr/source/openssh-SNAP-20161214/regress/unittests/hostkeys/testdata ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/match/test_match ; if test "xyes" = "xyes" ; then $V /usr/source/openssh-SNAP-20161214/regress/unittests/utf8/test_utf8 ; fi fi /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2.prv | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv tr '\n' '\r' /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_cr.prv /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_cr.prv | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv awk '{print $0 "\r"}' /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2.prv > /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_crnl.prv /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_crnl.prv | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv cat /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv > /usr/source/openssh-SNAP-20161214/regress//t2.out chmod 600 /usr/source/openssh-SNAP-20161214/regress//t2.out /usr/source/openssh-SNAP-20161214/ssh-keygen -yf /usr/source/openssh-SNAP-20161214/regress//t2.out | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub /usr/source/openssh-SNAP-20161214/ssh-keygen -ef /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub >/usr/source/openssh-SNAP-20161214/regress//t3.out /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress//t3.out | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub /usr/source/openssh-SNAP-20161214/ssh-keygen -E md5 -lf /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20161214/regress/t4.ok /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20161214/regress/t5.ok /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/dsa_ssh2.prv > /usr/source/openssh-SNAP-20161214/regress//t6.out1 /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/dsa_ssh2.pub > /usr/source/openssh-SNAP-20161214/regress//t6.out2 chmod 600 /usr/source/openssh-SNAP-20161214/regress//t6.out1 /usr/source/openssh-SNAP-20161214/ssh-keygen -yf /usr/source/openssh-SNAP-20161214/regress//t6.out1 | diff - /usr/source/openssh-SNAP-20161214/regress//t6.out2 /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t7.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t7.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t8.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t8.out > /dev/null test "yes" != yes || /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t9.out > /dev/null test "yes" != yes || /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t9.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t10.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t10.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -E sha256 -lf /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20161214/regress/t11.ok /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t12.out.pub | grep test-comment-1234 >/dev/null run test forwarding.sh ... generate keys wait for sshd start forwarding, fork to background transfer over forwarded channels and check result exit on -L forward failure, proto 2 exit on -R forward failure, proto 2 simple clear forwarding proto 2 clear local forward proto 2 clear remote forward proto 2 stdio forwarding proto 2 config file: start forwarding, fork to background config file: transfer over forwarded channels and check result Exit request sent. transfer over chained unix domain socket forwards and check result wait for sshd to exit ok local and remote forwarding all tests passed With FreeBSD non-modified openssl 1.0.2 And for the freebsd with daily modified openssl-1.0.2 make tests LTESTS=forwarding TEST_SSH_TRACE=yes SKIP_UNIT=1 [ -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 [ -d `pwd`/regress/unittests/match ] || mkdir -p `pwd`/regress/unittests/match [ -d `pwd`/regress/unittests/utf8 ] || mkdir -p `pwd`/regress/unittests/utf8 [ -d `pwd`/regress/misc/kexfuzz ] || mkdir -p `pwd`/regress/misc/kexfuzz [ -f `pwd`/regress/Makefile ] || ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile (cd openbsd-compat && make) 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_UTF8="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="AJRX" TEST_MALLOC_OPTIONS="AJRX" 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_UTF8="${TEST_SSH_UTF8}" TEST_SSH_ECC="${TEST_SSH_ECC}" TEST_SHELL="sh" EXEEXT="" tests && echo all tests passed test "x" = "x" || mkdir -p /usr/source/openssh-SNAP-20161214/regress//valgrind-out set -e ; if test -z "1" ; then V="" ; test "x" = "x" || V=/usr/source/openssh-SNAP-20161214/regress/valgrind-unit.sh ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/sshbuf/test_sshbuf ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/sshkey/test_sshkey -d /usr/source/openssh-SNAP-20161214/regress/unittests/sshkey/testdata ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/bitmap/test_bitmap ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/kex/test_kex ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/hostkeys/test_hostkeys -d /usr/source/openssh-SNAP-20161214/regress/unittests/hostkeys/testdata ; $V /usr/source/openssh-SNAP-20161214/regress/unittests/match/test_match ; if test "xyes" = "xyes" ; then $V /usr/source/openssh-SNAP-20161214/regress/unittests/utf8/test_utf8 ; fi fi /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2.prv | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv tr '\n' '\r' /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_cr.prv /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_cr.prv | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv awk '{print $0 "\r"}' /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2.prv > /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_crnl.prv /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/rsa_ssh2_crnl.prv | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv cat /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.prv > /usr/source/openssh-SNAP-20161214/regress//t2.out chmod 600 /usr/source/openssh-SNAP-20161214/regress//t2.out /usr/source/openssh-SNAP-20161214/ssh-keygen -yf /usr/source/openssh-SNAP-20161214/regress//t2.out | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub /usr/source/openssh-SNAP-20161214/ssh-keygen -ef /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub >/usr/source/openssh-SNAP-20161214/regress//t3.out /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress//t3.out | diff - /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub /usr/source/openssh-SNAP-20161214/ssh-keygen -E md5 -lf /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20161214/regress/t4.ok /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161220161214/regress/t5.ok /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/dsa_ssh2.prv > /usr/source/openssh-SNAP-20161214/regress//t6.out1 /usr/source/openssh-SNAP-20161214/ssh-keygen -if /usr/source/openssh-SNAP-20161214/regress/dsa_ssh2.pub > /usr/source/openssh-SNAP-20161214/regress//t6.out2 chmod 600 /usr/source/openssh-SNAP-20161214/regress//t6.out1 /usr/source/openssh-SNAP-20161214/ssh-keygen -yf /usr/source/openssh-SNAP-20161214/regress//t6.out1 | diff - /usr/source/openssh-SNAP-20161214/regress//t6.out2 /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t7.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t7.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t8.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t8.out > /dev/null test "yes" != yes || /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t9.out > /dev/null test "yes" != yes || /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t9.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t10.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -Bf /usr/source/openssh-SNAP-20161214/regress//t10.out > /dev/null /usr/source/openssh-SNAP-20161214/ssh-keygen -E sha256 -lf /usr/source/openssh-SNAP-20161214/regress/rsa_openssh.pub | awk '{print $2}' | diff - /usr/source/openssh-SNAP-20161214/regress/t11.ok /usr/source/openssh-SNAP-20161214/ssh-keygen -lf /usr/source/openssh-SNAP-20161214/regress//t12.out.pub | grep test-comment-1234 >/dev/null run test forwarding.sh ... generate keys wait for sshd start forwarding, fork to background transfer over forwarded channels and check result failed copy of /bin/ls cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy corrupted copy of /bin/ls exit on -L forward failure, proto 2 exit on -R forward failure, proto 2 simple clear forwarding proto 2 clear local forward proto 2 clear remote forward proto 2 stdio forwarding proto 2 config file: start forwarding, fork to background config file: transfer over forwarded channels and check result Exit request sent. transfer over chained unix domain socket forwards and check result wait for sshd to exit failed local and remote forwarding *** Error code 1 Stop. make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress *** Error code 1 Stop. make: stopped in /usr/source/openssh-SNAP-20161214 > > There might also be some clues in regress/failed* > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From doctor at doctor.nl2k.ab.ca Wed Dec 14 15:57:31 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 13 Dec 2016 21:57:31 -0700 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> Message-ID: <20161214045731.GB26640@doctor.nl2k.ab.ca> On Wed, Dec 14, 2016 at 12:55:57PM +1100, Darren Tucker wrote: > On Wed, Dec 14, 2016 at 12:22 PM, The Doctor wrote: > [tests] > > Stop. > > make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress > > *** Error code 1 > > There should be some files "failed-ssh.log" and "failed-sshd.log" in > the regress directory, which are the debug logs from the command > invocations that failed. They might give you some idea what went > wrong. > > [...] > > :-( What about libressl? > > Should work, we test against versions 2.1.8, 2.2.4, 2.2.8, 2.3.1, > 2.3.5, 2.4.0 (although the tests are currently lagging due to hardware > problems on the test box). > > Thanks. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. failed-regress.log trace: forward over UNIX and check result debug1: multiplexing control connection debug3: fd 6 is O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 1: new [mux-control] debug3: channel_post_mux_listener: new mux channel 1 fd 6 debug3: mux_master_read_cb: channel 1: hello sent debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: process_mux_master_hello: channel 1 slave version 4 debug3: mux_master_read_cb: channel 1 packet type 0x10000006 len 128 debug2: process_mux_open_fwd: channel 1: request local forward /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd:-2 -> /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd:-2 debug3: channel_setup_fwd_listener_streamlocal: type 18 path /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd debug1: Local forwarding listening on path /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd. debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: channel 3: new [unix listener] debug2: channel 1: ctl read<=0 rfd 6 len 0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: input drain -> closed debug2: channel 1: rcvd close debug2: channel 1: output open -> drain debug2: channel 1: obuf empty debug2: channel 1: close_write debug2: channel 1: chan_shutdown_write: shutdown() failed for fd 6: Socket is not connected debug2: channel 1: output drain -> closed debug2: channel 1: is dead (local) debug2: channel 1: gc: notify user debug3: mux_master_control_cleanup_cb: entering for channel 1 debug2: channel 1: gc: user detached debug2: channel 1: is dead (local) debug2: channel 1: garbage collecting debug1: channel 1: free: mux-control, nchannels 4 debug3: channel 1: status: The following connections are open: #1 mux-control (t16 r-1 i3/0 o3/0 fd 6/6 cc -1) debug1: multiplexing control connection debug3: fd 6 is O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 1: new [mux-control] debug3: channel_post_mux_listener: new mux channel 1 fd 6 debug3: mux_master_read_cb: channel 1: hello sent debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: process_mux_master_hello: channel 1 slave version 4 debug3: mux_master_read_cb: channel 1 packet type 0x10000006 len 128 debug2: process_mux_open_fwd: channel 1: request remote forward /usr/source/openssh-SNAP-20161214/regress/unix-3.fwd:-2 -> /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd:-2 debug3: send packet: type 80 debug3: receive packet: type 4 debug1: Remote: Server has disabled port forwarding. debug3: receive packet: type 82 debug1: mux_confirm_remote_forward: failure for: listen -2, connect /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd:-2 debug2: mux_confirm_remote_forward: clearing registered forwarding for listen -2, connect /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd:-2 mux_confirm_remote_forward: remote port forwarding failed for listen path /usr/source/openssh-SNAP-20161214/regress/unix-3.fwd debug2: channel 1: ctl read<=0 rfd 6 len 0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: input drain -> closed debug2: channel 1: rcvd close debug2: channel 1: output open -> drain debug2: channel 1: obuf empty debug2: channel 1: close_write debug2: channel 1: chan_shutdown_write: shutdown() failed for fd 6: Socket is not connected debug2: channel 1: output drain -> closed debug2: channel 1: is dead (local) debug2: channel 1: gc: notify user debug3: mux_master_control_cleanup_cb: entering for channel 1 debug2: channel 1: gc: user detached debug2: channel 1: is dead (local) debug2: channel 1: garbage collecting debug1: channel 1: free: mux-control, nchannels 4 debug3: channel 1: status: The following connections are open: #1 mux-control (t16 r-1 i3/0 o3/0 fd 6/6 cc -1) FAIL: ssh: corrupted copy of /usr/source/openssh-SNAP-20161214/regress/data trace: test connection multiplexing: cmd forward remote (UNIX) debug1: multiplexing control connection debug3: fd 6 is O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 1: new [mux-control] debug3: channel_post_mux_listener: new mux channel 1 fd 6 debug3: mux_master_read_cb: channel 1: hello sent debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: process_mux_master_hello: channel 1 slave version 4 debug3: mux_master_read_cb: channel 1 packet type 0x10000006 len 85 debug2: process_mux_open_fwd: channel 1: request remote forward /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd:-2 -> localhost:4242 debug3: send packet: type 80 debug3: receive packet: type 4 debug1: Remote: Server has disabled port forwarding. debug3: receive packet: type 82 debug1: mux_confirm_remote_forward: failure for: listen -2, connect localhost:4242 debug2: mux_confirm_remote_forward: clearing registered forwarding for listen -2, connect localhost:4242 mux_confirm_remote_forward: remote port forwarding failed for listen path /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd debug2: channel 1: ctl read<=0 rfd 6 len 0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: input drain -> closed debug2: channel 1: rcvd close debug2: channel 1: output open -> drain debug2: channel 1: obuf empty debug2: channel 1: close_write debug2: channel 1: chan_shutdown_write: shutdown() failed for fd 6: Socket is not connected debug2: channel 1: output drain -> closed debug2: channel 1: is dead (local) debug2: channel 1: gc: notify user debug3: mux_master_control_cleanup_cb: entering for channel 1 debug2: channel 1: gc: user detached debug2: channel 1: is dead (local) debug2: channel 1: garbage collecting debug1: channel 1: free: mux-control, nchannels 4 debug3: channel 1: status: The following connections are open: #1 mux-control (t16 r-1 i3/0 o3/0 fd 6/6 cc -1) FAIL: request remote forward failed trace: test connection multiplexing: cmd forward remote (UNIX) debug1: multiplexing control connection debug3: fd 6 is O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 1: new [mux-control] debug3: channel_post_mux_listener: new mux channel 1 fd 6 debug3: mux_master_read_cb: channel 1: hello sent debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: process_mux_master_hello: channel 1 slave version 4 debug3: mux_master_read_cb: channel 1 packet type 0x10000006 len 85 debug2: process_mux_open_fwd: channel 1: request remote forward /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd:-2 -> localhost:4242 debug3: send packet: type 80 debug3: receive packet: type 4 debug1: Remote: Server has disabled port forwarding. debug3: receive packet: type 82 debug1: mux_confirm_remote_forward: failure for: listen -2, connect localhost:4242 debug2: mux_confirm_remote_forward: clearing registered forwarding for listen -2, connect localhost:4242 mux_confirm_remote_forward: remote port forwarding failed for listen path /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd debug2: channel 1: ctl read<=0 rfd 6 len 0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: input drain -> closed debug2: channel 1: rcvd close debug2: channel 1: output open -> drain debug2: channel 1: obuf empty debug2: channel 1: close_write debug2: channel 1: chan_shutdown_write: shutdown() failed for fd 6: Socket is not connected debug2: channel 1: output drain -> closed debug2: channel 1: is dead (local) debug2: channel 1: gc: notify user debug3: mux_master_control_cleanup_cb: entering for channel 1 debug2: channel 1: gc: user detached debug2: channel 1: is dead (local) debug2: channel 1: garbage collecting debug1: channel 1: free: mux-control, nchannels 4 debug3: channel 1: status: The following connections are open: #1 mux-control (t16 r-1 i3/0 o3/0 fd 6/6 cc -1) FAIL: request remote forward failed FAIL: connect to remote forwarded path failed regress/failed-ssh.log trace: forward over UNIX and check result debug2: fd 4 setting O_NONBLOCK debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 1 local, 0 remote debug1: Requesting forwarding of local forward /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd:-2 -> /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd:-2 debug2: fd 4 setting O_NONBLOCK debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 1 remote debug1: Requesting forwarding of remote forward /usr/source/openssh-SNAP-20161214/regress/unix-3.fwd:-2 -> /usr/source/openssh-SNAP-20161214/regress/unix-2.fwd:-2 mux_client_forward: forwarding request failed: remote port forwarding failed for listen path /usr/source/openssh-SNAP-20161214/regress/unix-3.fwd muxclient: master forward request failed FAIL: ssh: corrupted copy of /usr/source/openssh-SNAP-20161214/regress/data trace: test connection multiplexing: cmd forward remote (UNIX) debug2: fd 4 setting O_NONBLOCK debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 1 remote debug1: Requesting forwarding of remote forward /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd:-2 -> localhost:4242 mux_client_forward: forwarding request failed: remote port forwarding failed for listen path /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd muxclient: master forward request failed FAIL: request remote forward failed trace: test connection multiplexing: cmd forward remote (UNIX) debug2: fd 4 setting O_NONBLOCK debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 1 remote debug1: Requesting forwarding of remote forward /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd:-2 -> localhost:4242 mux_client_forward: forwarding request failed: remote port forwarding failed for listen path /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd muxclient: master forward request failed FAIL: request remote forward failed FAIL: connect to remote forwarded path failed regress/failed-sshd.log trace: forward over UNIX and check result debug3: receive packet: type 80 debug1: server_input_global_request: rtype streamlocal-forward at openssh.com want_reply 1 debug1: server_input_global_request: streamlocal-forward listen path /usr/source/openssh-SNAP-20161214/regress/unix-3.fwd debug3: send packet: type 4 debug3: send packet: type 82 FAIL: ssh: corrupted copy of /usr/source/openssh-SNAP-20161214/regress/data trace: test connection multiplexing: cmd forward remote (UNIX) debug3: receive packet: type 80 debug1: server_input_global_request: rtype streamlocal-forward at openssh.com want_reply 1 debug1: server_input_global_request: streamlocal-forward listen path /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd debug3: send packet: type 4 debug3: send packet: type 82 FAIL: request remote forward failed trace: test connection multiplexing: cmd forward remote (UNIX) debug3: receive packet: type 80 debug1: server_input_global_request: rtype streamlocal-forward at openssh.com want_reply 1 debug1: server_input_global_request: streamlocal-forward listen path /usr/source/openssh-SNAP-20161214/regress/unix-1.fwd debug3: send packet: type 4 debug3: send packet: type 82 FAIL: request remote forward failed FAIL: connect to remote forwarded path failed -- 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 Merry Christmas 2016 and Happy New Year 2017 From jjelen at redhat.com Wed Dec 14 20:09:52 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Wed, 14 Dec 2016 10:09:52 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214012241.GA84711@doctor.nl2k.ab.ca> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> Message-ID: <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> On 12/14/2016 02:22 AM, The Doctor wrote: > run test forwarding.sh ... > failed copy of /bin/ls > cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy > corrupted copy of /bin/ls > Exit request sent. > failed local and remote forwarding > *** Error code 1 > > Stop. > make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress > *** Error code 1 > > Stop. > make: stopped in /usr/source/openssh-SNAP-20161214 I see very similar failures with vanilla openssh snapshot on Fedora 25. Should be quite fairly reproducible: # tar -xf openssh-SNAP-20161214.tar.gz && cd openssh && ./configure && make tests [...] test connection multiplexing: forward cmp: EOF on /root/openssh/regress/copy ssh: corrupted copy of /root/openssh/regress/data /root/openssh/regress/multiplex.sh: line 96: 18570 Terminated $NC -N -Ul $OBJ/unix-1.fwd < ${DATA} > /dev/null [...] request remote forward failed connect to remote forwarded path failed test connection multiplexing: cmd exit test connection multiplexing: cmd stop failed connection multiplexing Makefile:198: recipe for target 't-exec' failed make[1]: *** [t-exec] Error 1 make[1]: Leaving directory '/root/openssh/regress' Makefile:568: recipe for target 'tests' failed make: *** [tests] Error 2 I will have a look into that if I will have a minute today. -- Jakub Jelen Software Engineer Security Technologies Red Hat From jakob at kirei.se Wed Dec 14 20:23:19 2016 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 14 Dec 2016 10:23:19 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <8AEFC82B-CB9E-480A-A610-4CEC1B45EA11@kirei.se> On 2016-12-14 at 01:53, Damien Miller wrote: > OpenSSH 7.4 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. Those who want working X11 with macOS can take at https://github.com/jschlyter/openssh-portable/tree/osx. Perhaps it's not too late to merge this. jakob From Peter_Lawrence at belgocontrol.be Wed Dec 14 22:17:33 2016 From: Peter_Lawrence at belgocontrol.be (Peter_Lawrence at belgocontrol.be) Date: Wed, 14 Dec 2016 12:17:33 +0100 Subject: Seeking assistance with pubkey authentication problem on Windows OS Message-ID: Hello. May I please get your assistance regarding a road-block I've hit in setting up password-less ssh communication from a Linux host to a Windows client? The Linux machine that I am using inside the company network runs SUSE Linux version 3.0.101-0.31-default and has had OpenSSH_6.2p2 installed. I have installed OpenSSH-Win64 v0.0.4.0 on a Windows machine inside the same network that runs Windows 7 Professional 64-bit edition. I can successfully connect from the Linux to Windows machine using ssh, however after I create an rsa public key on the Linux machine (and transfer it to the appropriate .ssh folder used by OpenSSH on my Windows machine) I can not longer connect (Permission denied (publickey,keyboard-interactive)). Upon looking into the output when running sshd.exe in debug mode on my Windows machine I observed the following information: debug1: userauth-request for user LAW service ssh-connection method publickey debug1: attempt 2 failures 0 debug2: input_userauth_request: try method publickey debug3: userauth_pubkey: have signature for RSA SHA256:KaoUvZv0d5zAcj9ZGsJ9uM+Fi /p+pmp25pQywzNhriA debug3: w32_write fd:-1 debug1: w32_write ERROR: bad fd: -1 debug1: auth agent did not authorize client LAW debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa Failed publickey for LAW from 10.127.1.11 port 53773 ssh2: RSA SHA256:KaoUvZv0d5 zAcj9ZGsJ9uM+Fi/p+pmp25pQywzNhriA debug3: userauth_finish: failure partial=0 next methods="publickey,keyboard-inte ractive" The w32_write function in the source code of OpenSSH is coming up against a bad file descriptor at the public-key authentication stage, but I can't understand what this may be alluding to. All my folders related to the authorized_keys file have been given the correct permissions for my user (LAW), and the settings in the sshd_config file seem fine (I have set the line AuthorizedKeysFile C:\Users\LAW\.ssh\authorized_keys in this file, where the authorized_keys file was the direct copy of the rsa public key generated on the Linux side). I have also performed the ssh-lsa installation step for OpenSSH in Windows, which has successfully copied the ssh-lsa.dll file into the C:\Windows\System32 folder and has also added the entry ssh-lsa to the registry key "Authentication Packages" in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa I have of course restarted my Windows machine for these changes to have taken effect. All I'm doing as a test was to log in to the windows machine from the Linux machine using the shell command ssh LAW@ which works with my Windows password when there are no generated rsa public keys /root/.ssh folder on the Linux machine, however as soon as I generate a public key in this location I get the aforementioned problems with connection. I have noticed that not even ssh-copy-id works at this stage to copy over the public key to the Windows machine, and hence I am forced to use WinSCP on the Windows machine to copy over the key. Could you please assist me to find a solution. I have been able to get password-less ssh login working fine when installing Cygwin on the Windows machine with its openssh packages, however I wish to avoid the overhead of such an installation package on the Windows machine as I will be aiming to replicate the OpenSSH installation on many Windows machines thereafter. I thus wish to simply install OpenSSH to have an sshd service available and running on Windows. I wish to add that if I can get this password-less ssh connection working successfully, I will request for my company to make a financial contribution to the OpenSSH project once I replicate the installations and configurations on the Windows machines of other site users. I thank you for your time, and I look forward to your reply. Yours sincerely, Peter. ___________________________________________________________ Dr. Peter E. Lawrence BSc(Ma & Comp Sc)(Hons) MSc(Ma Sc)(Res) PhD(Ma Sc) Analyst & Software Engineer BELGOCONTROL (CANAC) Tervuursesteenweg 303 B - 1820 Steenokkerzeel Tel: [Office]: +32 2 206 2588 [GSM]: +32 4 701 80752 Email: law at belgocontrol.be Web: www.belgocontrol.be Belgocontrol Mail Disclaimer From vinschen at redhat.com Thu Dec 15 01:02:47 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 14 Dec 2016 15:02:47 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <20161214140247.GA5890@calimero.vinschen.de> Hi Damien, On Dec 14 11:53, Damien Miller wrote: > OpenSSH 7.4 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. Current git master tested on upcoming Cygwin 2.6.1 x86_64. Builds and runs out of the box, all regression tests pass. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Thu Dec 15 02:05:35 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 14 Dec 2016 08:05:35 -0700 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> Message-ID: <20161214150535.GA57472@doctor.nl2k.ab.ca> On Wed, Dec 14, 2016 at 10:09:52AM +0100, Jakub Jelen wrote: > On 12/14/2016 02:22 AM, The Doctor wrote: > > run test forwarding.sh ... > > failed copy of /bin/ls > > cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy > > corrupted copy of /bin/ls > > Exit request sent. > > failed local and remote forwarding > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/source/openssh-SNAP-20161214 > I see very similar failures with vanilla openssh snapshot on Fedora 25. > Should be quite fairly reproducible: > > # tar -xf openssh-SNAP-20161214.tar.gz && cd openssh && ./configure && > make tests > [...] > test connection multiplexing: forward > cmp: EOF on /root/openssh/regress/copy > ssh: corrupted copy of /root/openssh/regress/data > /root/openssh/regress/multiplex.sh: line 96: 18570 > Terminated $NC -N -Ul $OBJ/unix-1.fwd < ${DATA} > /dev/null > [...] > request remote forward failed > connect to remote forwarded path failed > test connection multiplexing: cmd exit > test connection multiplexing: cmd stop > failed connection multiplexing > Makefile:198: recipe for target 't-exec' failed > make[1]: *** [t-exec] Error 1 > make[1]: Leaving directory '/root/openssh/regress' > Makefile:568: recipe for target 'tests' failed > make: *** [tests] Error 2 > > I will have a look into that if I will have a minute today. > Isn't Fedora 25 in beta? > -- > Jakub Jelen > Software Engineer > Security Technologies > Red Hat > -- 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 Merry Christmas 2016 and Happy New Year 2017 From jjelen at redhat.com Thu Dec 15 02:23:38 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Wed, 14 Dec 2016 16:23:38 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214150535.GA57472@doctor.nl2k.ab.ca> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> <20161214150535.GA57472@doctor.nl2k.ab.ca> Message-ID: On 12/14/2016 04:05 PM, The Doctor wrote: > Isn't Fedora 25 in beta? Nope, Fedora 25 was released three weeks ago [1] [1] https://fedoraproject.org/wiki/Releases/25/Schedule -- Jakub Jelen Software Engineer Security Technologies Red Hat From Peter_Lawrence at belgocontrol.be Thu Dec 15 02:34:40 2016 From: Peter_Lawrence at belgocontrol.be (Peter_Lawrence at belgocontrol.be) Date: Wed, 14 Dec 2016 16:34:40 +0100 Subject: Seeking assistance with pubkey authentication problem on Windows OS Message-ID: Hello. I did a bit more digging in the debug information and I have isolated the problem, which looks like it comes directly from the source code.? The ssh-agent.log shows the following entries during my ssh connection attempt from the Linux machine to the Windows machine running a Win64 OpenSSH: 5772 16:13:37 990 debug1: trying public key file C:\Users\LAW/.ssh\authorized_keys 5772 16:13:37 990 debug1: given public key is not mapped to user LAW (profile:C:\Users\LAW) My sshd_config file has been set with the following entry: AuthorizedKeysFile?.ssh\authorized_keys I have noticed that if I was to?either use the line AuthorizedKeysFile %h\.ssh\authorized_keys or AuthorizedKeysFile?C:\Users\LAW\.ssh\authorized_keys the?ssh-agent.log shows a debug entry now saying? trying public key file C:\Users\LAW/C:\Users\LAW\.ssh\authorized_keys Having had a dig around in the source-code for OpenSSH, the culprit is the subroutine expand_authorized_keys in the file auth.c which returns a char pointer called ret given by snprintf(ret, sizeof(ret), "%s/%s", pw->pw_dir, file) You can see here that the formatting?"%s/%s" is causing the insertion of a forward-slash in the?public key filename used in the windows environment; to this extent, the?authorized_keys?file will never be found in the windows environment. Would it suffice if I rebuild the Win64 OpenSSH executables with the correction?snprintf(ret, sizeof(ret), "%s\\%s", pw->pw_dir, file), or should I wait for an official build with this correction? Yours sincerely, Peter. ___________________________________________________________ Dr. Peter E. Lawrence? BSc(Ma & Comp Sc)(Hons) MSc(Ma Sc)(Res) PhD(Ma Sc) Analyst & Software Engineer BELGOCONTROL?(CANAC) Tervuursesteenweg?303 B?-?1820?Steenokkerzeel Tel:?[Office]:? +32?2?206?2588 ?????? [GSM]:? ?+32 4 701 80752 Email: law at belgocontrol.be Web:??www.belgocontrol.be ? Belgocontrol Mail Disclaimer From hecht at hlrs.de Thu Dec 15 03:13:33 2016 From: hecht at hlrs.de (Martin Hecht) Date: Wed, 14 Dec 2016 17:13:33 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <9eb0f8f0-d6e1-18ca-20eb-c7d10b880bfb@hlrs.de> all tests passed on - Ubuntu 14.04.5 LTS - Scientific Linux release 6.8 - SUSE Linux Enterprise Server 11 SP3 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5254 bytes Desc: S/MIME Cryptographic Signature URL: From manojampalam at gmail.com Thu Dec 15 04:21:18 2016 From: manojampalam at gmail.com (Manoj K. Ampalam) Date: Wed, 14 Dec 2016 09:21:18 -0800 Subject: Seeking assistance with pubkey authentication problem on Windows OS In-Reply-To: References: Message-ID: Please file an issue at https://github.com/PowerShell/Win32-OpenSSH. The Windows fork is not part of the main OpenSSH project yet. Otherwise, you may work around your issue by getting rid of this configuration line: AuthorizedKeysFile %h\.ssh\authorized_keys It would default to %userprofile%\.ssh\authorized_keys. On Wed, Dec 14, 2016 at 7:34 AM, Peter_Lawrence at belgocontrol.be < Peter_Lawrence at belgocontrol.be> wrote: > Hello. > > I did a bit more digging in the debug information and I have isolated the > problem, which looks like it comes directly from the source code. > The ssh-agent.log shows the following entries during my ssh connection > attempt from the Linux machine to the Windows machine running a Win64 > OpenSSH: > > 5772 16:13:37 990 debug1: trying public key file > C:\Users\LAW/.ssh\authorized_keys > 5772 16:13:37 990 debug1: given public key is not mapped to user LAW > (profile:C:\Users\LAW) > > My sshd_config file has been set with the following entry: > AuthorizedKeysFile .ssh\authorized_keys > > I have noticed that if I was to either use the line > AuthorizedKeysFile %h\.ssh\authorized_keys > or > AuthorizedKeysFile C:\Users\LAW\.ssh\authorized_keys > the ssh-agent.log shows a debug entry now saying > trying public key file C:\Users\LAW/C:\Users\LAW\.ssh\authorized_keys > > Having had a dig around in the source-code for OpenSSH, the culprit is the > subroutine > expand_authorized_keys > in the file auth.c > which returns a char pointer called ret given by snprintf(ret, > sizeof(ret), "%s/%s", pw->pw_dir, file) > You can see here that the formatting "%s/%s" is causing the insertion of a > forward-slash in the public key filename used in the windows environment; > to this extent, the authorized_keys file will never be found in the windows > environment. > > Would it suffice if I rebuild the Win64 OpenSSH executables with the > correction snprintf(ret, sizeof(ret), "%s\\%s", pw->pw_dir, file), or > should I wait for an official build with this correction? > > > Yours sincerely, > Peter. > > ___________________________________________________________ > > Dr. Peter E. Lawrence BSc(Ma & Comp Sc)(Hons) MSc(Ma Sc)(Res) PhD(Ma Sc) > Analyst & Software Engineer > BELGOCONTROL (CANAC) > Tervuursesteenweg 303 > B - 1820 Steenokkerzeel > Tel: [Office]: +32 2 206 2588 > [GSM]: +32 4 701 80752 > Email: law at belgocontrol.be > Web: www.belgocontrol.be > > > Belgocontrol Mail Disclaimer > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From mike at sentex.net Thu Dec 15 06:44:59 2016 From: mike at sentex.net (Mike Tancsa) Date: Wed, 14 Dec 2016 14:44:59 -0500 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: References: Message-ID: <0e6433b0-cb90-30df-bb04-6e43dd9bdcfa@sentex.net> On 12/13/2016 2:00 PM, Kenny Simpson wrote: > Hello, > Is there any support (existing or planned) for host keys/certs being > managed by some hardware device (tpm,hsm,etc..) instead of a flat > file? Not sure if this is what you are after ? http://www.tancsa.com/mdtblog/?p=73 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From uri at ll.mit.edu Thu Dec 15 06:58:16 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 14 Dec 2016 19:58:16 +0000 Subject: Call for testing: OpenSSH 7.4 Message-ID: <20161214195801.18280523.8231.106777@ll.mit.edu> I for one would like to see it merged.? Thanks! Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Jakob Schlyter Sent: Wednesday, December 14, 2016 04:29 To: openssh-unix-dev at mindrot.org Subject: Re: Call for testing: OpenSSH 7.4 On 2016-12-14 at 01:53, Damien Miller wrote: > OpenSSH 7.4 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. Those who want working X11 with macOS can take at https://github.com/jschlyter/openssh-portable/tree/osx. Perhaps it's not too late to merge this. jakob _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From dtucker at zip.com.au Thu Dec 15 11:05:47 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Dec 2016 11:05:47 +1100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161214195801.18280523.8231.106777@ll.mit.edu> References: <20161214195801.18280523.8231.106777@ll.mit.edu> Message-ID: On Thu, Dec 15, 2016 at 6:58 AM, Blumenthal, Uri - 0553 - MITLL wrote: [OSX launchd diff] > I for one would like to see it merged. I took the patch and addressed the comments in https://bugzilla.mindrot.org/show_bug.cgi?id=2341. If we can get some confirmation that it (https://bugzilla.mindrot.org/attachment.cgi?id=2915&action=edit) works OK we might be able to get that in. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From adam at continusec.com Thu Dec 15 11:49:45 2016 From: adam at continusec.com (Adam Eijdenberg) Date: Thu, 15 Dec 2016 11:49:45 +1100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: On Wed, Dec 14, 2016 at 11:53 AM Damien Miller wrote: > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. CentOS 7.2.1511 - all tests passed CentOS 6.5 - all tests passed Mac OS X 10.11.6 (15G1108) - all tests passed From zev at bewilderbeest.net Thu Dec 15 16:22:51 2016 From: zev at bewilderbeest.net (Zev Weiss) Date: Wed, 14 Dec 2016 23:22:51 -0600 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> On Wed, Dec 14, 2016 at 11:53:32AM +1100, Damien Miller wrote: >Hi, > >OpenSSH 7.4 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. > Hi, I tested (or tried) git commit b737e4d7 on three systems, with somewhat mixed results. On Mac OSX (macOS?) 10.9, configure failed with: ... checking OpenSSL header version... 1000208f (OpenSSL 1.0.2h 3 May 2016) checking OpenSSL library version... 009081df (OpenSSL 0.9.8zg 14 July 2015) checking whether OpenSSL's headers match the library... no configure: error: Your OpenSSL headers do not match your library. Check config.log for details. A second attempt with configure's openssl-dir pointed at a macports install in /opt/local built successfully and passed all tests, though there were some warnings during the build (mostly noticed just because I configured with -Werror and then manually papered over them; not sure how important these really are): - daemon() deprecated (ssh.c, sshd.c) - utmp, login, logout, logwtmp deprecated (loginrec.c) - sandbox_init() deprecated (sandbox-darwin.c) - struct monitor declared in ssh_sandbox_init() parameter list (sandbox-darwin.c) - set-but-unused 'flag' variable in sys_tun_open() (port-tun.c) On Void Linux (which uses LibreSSL, for what it's worth): unable to compile due to undeclared arc4random*() functions. The symbols exist in libcrypto so configure's tests for them pass, but they're not declared in any header files. I'm not sure where exactly these are "supposed" to be declared, so I don't know if this is a problem with OpenSSH or LibreSSL or some packaging bungle on Void's part. On Debian testing: discovered a small-but-significant problem in auth.c's allowed_user() function. Commit 010359b3 expanded the body of the loop that checks DenyUsers entries, but didn't add the necessary braces around it, so it didn't exactly have the intended effect, instead resulting in only the last entry in DenyUsers actually being enforced. (Credit to gcc's -Wmisleading-indentation warning here.) The attached patch 0001-Unbreak-DenyUsers-with-1-user-specified.patch fixes the bug; the next two patches (0002-Add-and-use-stop_sshd-helper-function.patch and 0003-Add-regression-test-for-AllowUsers-DenyUsers.patch) add a regression test that detects it (failing before and passing after patch 0001). With those patches applied a -Werror build completed successfully and passed all tests. (I also noticed a mis-typed error message in dh.c, addressed in the attached 0004-Fix-mis-worded-error-message-in-choose_dh.patch.) Thanks, Zev -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Unbreak-DenyUsers-with-1-user-specified.patch Type: text/x-diff Size: 1129 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-and-use-stop_sshd-helper-function.patch Type: text/x-diff Size: 2222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-regression-test-for-AllowUsers-DenyUsers.patch Type: text/x-diff Size: 2739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-mis-worded-error-message-in-choose_dh.patch Type: text/x-diff Size: 725 bytes Desc: not available URL: From theonetruekenny at gmail.com Thu Dec 15 17:45:01 2016 From: theonetruekenny at gmail.com (Kenny Simpson) Date: Thu, 15 Dec 2016 01:45:01 -0500 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: <0e6433b0-cb90-30df-bb04-6e43dd9bdcfa@sentex.net> References: <0e6433b0-cb90-30df-bb04-6e43dd9bdcfa@sentex.net> Message-ID: yes, I found this after getting clued into HostKeyAgent. Any updates since the post, or has it Just Worked ever since? thanks, -Kenny On Wed, Dec 14, 2016 at 2:44 PM, Mike Tancsa wrote: > On 12/13/2016 2:00 PM, Kenny Simpson wrote: >> Hello, >> Is there any support (existing or planned) for host keys/certs being >> managed by some hardware device (tpm,hsm,etc..) instead of a flat >> file? > > Not sure if this is what you are after ? > > http://www.tancsa.com/mdtblog/?p=73 > > ---Mike > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike at sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ From raphael.medaer at escaux.com Thu Dec 15 21:26:06 2016 From: raphael.medaer at escaux.com (Raphael Medaer) Date: Thu, 15 Dec 2016 11:26:06 +0100 Subject: [PATCH] Server specified remote bind address Message-ID: Hi OpenSSH community, The following patch cover the use cases where sshd must force/override remote forwarding bind address. I'm mainly using it to force a given user listening on a loopback address. It avoids port binding conflicts and allow me to restrict a given group or user to a specific address. Example: # sshd configuration file Match User remote GatewayPorts serverspecified ForwardingBindAddress 127.1.0.2 As attached file you'll find the patch which improves and implements two options in sshd_config: * GatewayPorts: I added option "serverspecified" to list of available values. When this option is given, sshd will override remote port forwarding to bind on server specified address "ForwardingBindAddress". * ForwardingBindAddress: Defines on which address sshd must bind when GatewayPorts = serverspecified. The goal of this mail is (of course) to share with you the patch, but also to get feedback about the idea it-self and implementation as well. Best regards, -- Raphael Medaer Product Development Engineer Escaux Escaux, the nr 1 alternative in Unified Communication Chauss?e de Bruxelles 408, 1300 Wavre, Belgium Direct: +3227887564 Main: +3226860900 www.escaux.com -------------- next part -------------- A non-text attachment was scrubbed... Name: server-specified-bind-address.patch Type: text/x-patch Size: 5163 bytes Desc: not available URL: From jakob at kirei.se Thu Dec 15 23:38:57 2016 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 15 Dec 2016 13:38:57 +0100 Subject: Working X11 with macOS In-Reply-To: References: <20161214195801.18280523.8231.106777@ll.mit.edu> Message-ID: <4D04D343-8CB3-4CBD-A800-C89C3A1694A2@kirei.se> On 2016-12-15 at 01:05, Darren Tucker wrote: > On Thu, Dec 15, 2016 at 6:58 AM, Blumenthal, Uri - 0553 - MITLL > wrote: > [OSX launchd diff] >> I for one would like to see it merged. > > I took the patch and addressed the comments in > https://bugzilla.mindrot.org/show_bug.cgi?id=2341. If we can get some > confirmation that it > (https://bugzilla.mindrot.org/attachment.cgi?id=2915&action=edit) > works OK we might be able to get that in. People running macOS, please test this patch by doing X11 forwarding with macOS client to any server. To get current code easiser, use branch 'osx' from repo https://github.com/jschlyter/openssh-portable.git. jakob From mike at sentex.net Fri Dec 16 01:21:55 2016 From: mike at sentex.net (Mike Tancsa) Date: Thu, 15 Dec 2016 09:21:55 -0500 Subject: pkcs #11/hardware support for server keys/sshd? In-Reply-To: References: <0e6433b0-cb90-30df-bb04-6e43dd9bdcfa@sentex.net> Message-ID: <1e958238-158a-a5f7-48b2-cab54e1ae67e@sentex.net> On 12/15/2016 1:45 AM, Kenny Simpson wrote: > yes, I found this after getting clued into HostKeyAgent. > Any updates since the post, or has it Just Worked ever since? It just works. Its a pretty low volume site and restricted to certain networks only. If it were internet facing, I would probably put some sort of port knocking in front of it as these keys tend not to be the fastest and bots brute forcing might DoS it. I hadnt done any heavy load testing. It easily survived my worst case load tests so I didnt bother going beyond that to see at what point it would break down compared to storing the private key in a file. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From wieland at purdue.edu Fri Dec 16 08:03:11 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Thu, 15 Dec 2016 16:03:11 -0500 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <5853050F.9060300@purdue.edu> Damien Miller wrote: > Hi, > > OpenSSH 7.4 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. > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > SPARC Solaris 10, using our local build of OpenSSL 1.0.2j, compiled in 32 bit mode with Sun/Solaris/Oracle Studio 12.[024], passes all tests. I haven't been able to run the tests using Oracle's build of OpenSSL, which is sort of in a state of flux :-). -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms From htodd at twofifty.com Fri Dec 16 12:17:08 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Thu, 15 Dec 2016 17:17:08 -0800 (PST) Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: Once I created /var/empty, test passed on NetBSD-current and NetBSD-7 (both amd64). -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From dtucker at zip.com.au Fri Dec 16 15:06:25 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 16 Dec 2016 15:06:25 +1100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> References: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> Message-ID: On Thu, Dec 15, 2016 at 4:22 PM, Zev Weiss wrote: [...] > I tested (or tried) git commit b737e4d7 on three systems, with somewhat > mixed results. Thanks for the comprehensive testing! > On Mac OSX (macOS?) 10.9, configure failed with: > > ... > checking OpenSSL header version... 1000208f (OpenSSL 1.0.2h 3 May 2016) > checking OpenSSL library version... 009081df (OpenSSL 0.9.8zg 14 July > 2015) > checking whether OpenSSL's headers match the library... no > configure: error: Your OpenSSL headers do not match your > library. Check config.log for details. I think that's due to the headers and libraries supplied (or not) by Apple. > A second attempt with configure's openssl-dir pointed at a macports install > in /opt/local built successfully and passed all tests, though there were > some warnings during the build (mostly noticed just because I configured > with -Werror and then manually papered over them; not sure how important > these really are): > > - daemon() deprecated (ssh.c, sshd.c) > - utmp, login, logout, logwtmp deprecated (loginrec.c) > - sandbox_init() deprecated (sandbox-darwin.c) I don't think there's much we can do about these without abandoning earlier OS releases. > - struct monitor declared in ssh_sandbox_init() parameter list > (sandbox-darwin.c) Missing monitor.h include. Harmless (it's never used), now fixed. > - set-but-unused 'flag' variable in sys_tun_open() (port-tun.c) True, the code that uses it is inside an ifdef. Might look at this later. > On Void Linux (which uses LibreSSL, for what it's worth): unable to compile > due to undeclared arc4random*() functions. The symbols exist in libcrypto > so configure's tests for them pass, but they're not declared in any header > files. I'm not sure where exactly these are "supposed" to be declared, so I > don't know if this is a problem with OpenSSH or LibreSSL or some packaging > bungle on Void's part. Don't know about this one. Might install a VM to look at this if I get a chance. > On Debian testing: discovered a small-but-significant problem in auth.c's > allowed_user() function. Commit 010359b3 expanded the body of the loop that > checks DenyUsers entries, but didn't add the necessary braces around it, so > it didn't exactly have the intended effect, instead resulting in only the > last entry in DenyUsers actually being enforced. (Credit to gcc's > -Wmisleading-indentation warning here.) Nice find! Fixed. > The attached patch 0001-Unbreak-DenyUsers-with-1-user-specified.patch fixes > the bug; the next two patches All patches applied. Thank you. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Dec 16 15:16:50 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Dec 2016 15:16:50 +1100 (AEDT) Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> References: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> Message-ID: On Wed, 14 Dec 2016, Zev Weiss wrote: > Hi, > > I tested (or tried) git commit b737e4d7 on three systems, with somewhat mixed > results. Thanks for the testing and fixes, and even more for taking the time to write a regression test! -d From kevin.brott at gmail.com Fri Dec 16 18:07:27 2016 From: kevin.brott at gmail.com (Kevin Brott) Date: Thu, 15 Dec 2016 23:07:27 -0800 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <41ebc47d-2067-23ed-9074-67f910c10fec@gmail.com> On 12/15/2016 05:17 PM, Hisashi T Fujinaka wrote: > Once I created /var/empty, test passed on NetBSD-current and NetBSD-7 > (both amd64). > Likewise on Debian 8.6. Will try to start the runs against the build farm @ work, assuming our change-freeze on production work is still in place. :p -- # include /* Kevin Brott */ From zev at bewilderbeest.net Sat Dec 17 06:30:03 2016 From: zev at bewilderbeest.net (Zev Weiss) Date: Fri, 16 Dec 2016 13:30:03 -0600 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> Message-ID: <20161216193002.ekr5gyy77jcovrqb@hatter.bewilderbeest.net> On Fri, Dec 16, 2016 at 03:06:25PM +1100, Darren Tucker wrote: >> The attached patch 0001-Unbreak-DenyUsers-with-1-user-specified.patch >> fixes >> the bug; the next two patches > >All patches applied. > Great, thanks -- I see it all upstream, but the patch adding the new allow-deny-user regression test doesn't seem to have filtered down into -portable. Did that one fall through the cracks or is it just still in the pipeline? Zev From nicholas.marriott at gmail.com Sat Dec 17 07:10:04 2016 From: nicholas.marriott at gmail.com (Nicholas Marriott) Date: Fri, 16 Dec 2016 20:10:04 +0000 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> Message-ID: <20161216201004.GE49264@yelena> Hi On Fri, Dec 16, 2016 at 03:06:25PM +1100, Darren Tucker wrote: > On Thu, Dec 15, 2016 at 4:22 PM, Zev Weiss wrote: > [...] > > On Void Linux (which uses LibreSSL, for what it's worth): unable to compile > > due to undeclared arc4random*() functions. The symbols exist in libcrypto > > so configure's tests for them pass, but they're not declared in any header > > files. I'm not sure where exactly these are "supposed" to be declared, so I > > don't know if this is a problem with OpenSSH or LibreSSL or some packaging > > bungle on Void's part. > > Don't know about this one. Might install a VM to look at this if I > get a chance. Look out for a similar problem with strlcpy and strlcat - libressl exports those (so AC_CHECK_FUNC will find them), but there are no prototypes. I hit this on another project, ended up just changing to use AC_CHECK_DECL instead of AC_CHECK_FUNC. From dtucker at zip.com.au Sat Dec 17 08:15:44 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 17 Dec 2016 08:15:44 +1100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <20161216193002.ekr5gyy77jcovrqb@hatter.bewilderbeest.net> References: <20161215052250.54o4sf5cbd3m25ng@hatter.bewilderbeest.net> <20161216193002.ekr5gyy77jcovrqb@hatter.bewilderbeest.net> Message-ID: On Sat, Dec 17, 2016 at 6:30 AM, Zev Weiss wrote: [..] > Great, thanks -- I see it all upstream, but the patch adding the new > allow-deny-user regression test doesn't seem to have filtered down into > -portable. Did that one fall through the cracks or is it just still in the > pipeline? It's just in the pipeline, we haven't done a sync since I committed it to OpenBSD. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From philipp at vlassakakis.de Sun Dec 18 11:37:59 2016 From: philipp at vlassakakis.de (Philipp Vlassakakis) Date: Sun, 18 Dec 2016 01:37:59 +0100 Subject: Extend logging of openssh-server - e.g. plaintext password Message-ID: Dear list members, I want to extend the logging of the openssh-server, so it also logs the entered passwords in plaintext, and yes I know that this is a security issue, but relax, Password Authentication is disabled. ;) The logging is only used for collecting data on my honeypots. After digging through the source, I?ve found a file called ?auth.c" auth.c: #ifdef CUSTOM_FAILED_LOGIN if (authenticated == 0 && !authctxt->postponed && (strcmp(method, "password") == 0 || strncmp(method, "keyboard-interactive", 20) == 0 || strcmp(method, "challenge-response") == 0)) record_failed_login(authctxt->user, get_canonical_hostname(options.use_dns), "ssh"); # ifdef WITH_AIXAUTHENTICATE if (authenticated) sys_auth_record_login(authctxt->user, get_canonical_hostname(options.use_dns), "ssh", &loginmsg); # endif #endif? Now I?ve just thought adding ?authctxt->password? should do the trick?unfortunately not. Is there any way to implement this? Thanks. Philipp From lists at spuddy.org Sun Dec 18 11:48:23 2016 From: lists at spuddy.org (Stephen Harris) Date: Sat, 17 Dec 2016 19:48:23 -0500 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: References: Message-ID: <20161218004823.GA7424@mercury7.spuddy.org> On Sun, Dec 18, 2016 at 01:37:59AM +0100, Philipp Vlassakakis wrote: > I want to extend the logging of the openssh-server, so it also logs the entered passwords in plaintext, and yes I know that this is a security issue, but relax, Password Authentication is disabled. ;) > > The logging is only used for collecting data on my honeypots. ... > Is there any way to implement this? I explored this a few months back in a blog entry: https://www.sweharris.org/post/2016-09-18-ssh-password-exposure/ -- rgds Stephen From philipp at vlassakakis.de Sun Dec 18 19:27:33 2016 From: philipp at vlassakakis.de (Philipp Vlassakakis) Date: Sun, 18 Dec 2016 09:27:33 +0100 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: <20161218004823.GA7424@mercury7.spuddy.org> References: <20161218004823.GA7424@mercury7.spuddy.org> Message-ID: Works like a charm. Thanks Stephen! :) > Am 18.12.2016 um 01:48 schrieb Stephen Harris : > > On Sun, Dec 18, 2016 at 01:37:59AM +0100, Philipp Vlassakakis wrote: >> I want to extend the logging of the openssh-server, so it also logs the entered passwords in plaintext, and yes I know that this is a security issue, but relax, Password Authentication is disabled. ;) >> >> The logging is only used for collecting data on my honeypots. > ... >> Is there any way to implement this? > > I explored this a few months back in a blog entry: > https://www.sweharris.org/post/2016-09-18-ssh-password-exposure/ > From nkadel at gmail.com Sun Dec 18 21:21:46 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 18 Dec 2016 05:21:46 -0500 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: References: Message-ID: On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis wrote: > Dear list members, > > I want to extend the logging of the openssh-server, so it also logs the entered passwords in plaintext, and yes I know that this is a security issue, but relax, Password Authentication is disabled. ;) Oh, dear lord. What part of "a really bad idea and begging for pure abuse" is not clear about this idea? Simply setting up a fake server with a hostname similar to a common could encourage password harvesting. It would be much safer to simply avoid activating debugging tools that can be so abused. From philipp at vlassakakis.de Mon Dec 19 01:42:18 2016 From: philipp at vlassakakis.de (Philipp Vlassakakis) Date: Sun, 18 Dec 2016 15:42:18 +0100 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: References: Message-ID: <5B50BCC1-1FEE-48F1-8EF7-6BA77CE68DDB@vlassakakis.de> What part of ?Password Authentication is disabled? do you not understand? > Am 18.12.2016 um 11:21 schrieb Nico Kadel-Garcia : > > On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis > wrote: >> Dear list members, >> >> I want to extend the logging of the openssh-server, so it also logs the entered passwords in plaintext, and yes I know that this is a security issue, but relax, Password Authentication is disabled. ;) > > Oh, dear lord. What part of "a really bad idea and begging for pure > abuse" is not clear about this idea? Simply setting up a fake server > with a hostname similar to a common could encourage password > harvesting. > > It would be much safer to simply avoid activating debugging tools that > can be so abused. From nkadel at gmail.com Mon Dec 19 03:48:44 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 18 Dec 2016 11:48:44 -0500 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: <5B50BCC1-1FEE-48F1-8EF7-6BA77CE68DDB@vlassakakis.de> References: <5B50BCC1-1FEE-48F1-8EF7-6BA77CE68DDB@vlassakakis.de> Message-ID: On Sun, Dec 18, 2016 at 9:42 AM, Philipp Vlassakakis wrote: > What part of ?Password Authentication is disabled? do you not understand? > > > Am 18.12.2016 um 11:21 schrieb Nico Kadel-Garcia : > > On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis > wrote: > > Dear list members, > > I want to extend the logging of the openssh-server, so it also logs the > entered passwords in plaintext, and yes I know that this is a security > issue, but relax, Password Authentication is disabled. ;) > > > Oh, dear lord. What part of "a really bad idea and begging for pure > abuse" is not clear about this idea? Simply setting up a fake server > with a hostname similar to a common could encourage password > harvesting. > > It would be much safer to simply avoid activating debugging tools that > can be so abused. What part of "actively supporting honeypots is a bad idea" is unclear to you, sir? This kind of built-in feature can, and will, be used by malicious people to activate passphrase theft. By activating it directly in the source code, it also makes it that much more difficult to detect when someone can and has enabled such harvesting. From uri at ll.mit.edu Mon Dec 19 04:05:41 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 18 Dec 2016 17:05:41 +0000 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: References: <5B50BCC1-1FEE-48F1-8EF7-6BA77CE68DDB@vlassakakis.de> Message-ID: <83952911-73F0-40CE-8FEE-FDCF627E8568@ll.mit.edu> I concur with Nico ? logging plaintext passwords is an extremely bad idea. The tone of the poster also leaves much to be desired ? but I?ll hold my tongue for now. -- Regards, Uri Blumenthal On 12/18/16, 11:48, "openssh-unix-dev on behalf of Nico Kadel-Garcia" wrote: On Sun, Dec 18, 2016 at 9:42 AM, Philipp Vlassakakis wrote: > What part of ?Password Authentication is disabled? do you not understand? > > > Am 18.12.2016 um 11:21 schrieb Nico Kadel-Garcia : > > On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis > wrote: > > Dear list members, > > I want to extend the logging of the openssh-server, so it also logs the > entered passwords in plaintext, and yes I know that this is a security > issue, but relax, Password Authentication is disabled. ;) > > > Oh, dear lord. What part of "a really bad idea and begging for pure > abuse" is not clear about this idea? Simply setting up a fake server > with a hostname similar to a common could encourage password > harvesting. > > It would be much safer to simply avoid activating debugging tools that > can be so abused. What part of "actively supporting honeypots is a bad idea" is unclear to you, sir? This kind of built-in feature can, and will, be used by malicious people to activate passphrase theft. By activating it directly in the source code, it also makes it that much more difficult to detect when someone can and has enabled such harvesting. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From tgc at jupiterrise.com Mon Dec 19 04:05:35 2016 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Sun, 18 Dec 2016 18:05:35 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: On 14/12/16 01:53, Damien Miller wrote: > Hi, > > OpenSSH 7.4 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. I've tested Solaris 2.6/sparc, 7/sparc, 8/sparc and 9/x86 using HEAD from the git repo. All exhihit this error: test_utf8: .. regress/unittests/utf8/tests.c:52 test #3 "utf8_null" ASSERT_STRING_EQ(buf, wants) failed: buf = (NULL) (len zu) wants = (null) (len zu) gmake[1]: *** [unit] Error 134 -tgc From philipp at vlassakakis.de Mon Dec 19 04:26:55 2016 From: philipp at vlassakakis.de (Philipp Vlassakakis) Date: Sun, 18 Dec 2016 18:26:55 +0100 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: <83952911-73F0-40CE-8FEE-FDCF627E8568@ll.mit.edu> References: <5B50BCC1-1FEE-48F1-8EF7-6BA77CE68DDB@vlassakakis.de> <83952911-73F0-40CE-8FEE-FDCF627E8568@ll.mit.edu> Message-ID: Please accept my apologies. Sorry if my previous mails sound rude, it was not my intention. @Nico: What do you mean with ?setting up a fake server? ? Should I change my SSH-Port to a non-default port and install a SSH-Honeypot like Kippo, which listens on Port 22 as my ?SSH-Honeypot-Password-Harvester? ? With this solution i don?t have to modify the source code of the openssh-server-package. Regards, Philipp > Am 18.12.2016 um 18:05 schrieb Blumenthal, Uri - 0553 - MITLL : > > I concur with Nico ? logging plaintext passwords is an extremely bad idea. > > The tone of the poster also leaves much to be desired ? but I?ll hold my tongue for now. > -- > Regards, > Uri Blumenthal > > On 12/18/16, 11:48, "openssh-unix-dev on behalf of Nico Kadel-Garcia" wrote: > > On Sun, Dec 18, 2016 at 9:42 AM, Philipp Vlassakakis > wrote: >> What part of ?Password Authentication is disabled? do you not understand? >> >> >> Am 18.12.2016 um 11:21 schrieb Nico Kadel-Garcia : >> >> On Sat, Dec 17, 2016 at 7:37 PM, Philipp Vlassakakis >> wrote: >> >> Dear list members, >> >> I want to extend the logging of the openssh-server, so it also logs the >> entered passwords in plaintext, and yes I know that this is a security >> issue, but relax, Password Authentication is disabled. ;) >> >> >> Oh, dear lord. What part of "a really bad idea and begging for pure >> abuse" is not clear about this idea? Simply setting up a fake server >> with a hostname similar to a common could encourage password >> harvesting. >> >> It would be much safer to simply avoid activating debugging tools that >> can be so abused. > > What part of "actively supporting honeypots is a bad idea" is unclear > to you, sir? This kind of built-in feature can, and will, be used by > malicious people to activate passphrase theft. By activating it > directly in the source code, it also makes it that much more difficult > to detect when someone can and has enabled such harvesting. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From nkadel at gmail.com Mon Dec 19 04:56:17 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 18 Dec 2016 12:56:17 -0500 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: References: <5B50BCC1-1FEE-48F1-8EF7-6BA77CE68DDB@vlassakakis.de> <83952911-73F0-40CE-8FEE-FDCF627E8568@ll.mit.edu> Message-ID: On Sun, Dec 18, 2016 at 12:26 PM, Philipp Vlassakakis wrote: > Please accept my apologies. Sorry if my previous mails sound rude, it was not my intention. > > @Nico: > What do you mean with ?setting up a fake server? ? > Should I change my SSH-Port to a non-default port and install a SSH-Honeypot like Kippo, which listens on Port 22 as my ?SSH-Honeypot-Password-Harvester? ? > > With this solution i don?t have to modify the source code of the openssh-server-package. > > Regards, > Philipp By setting up a fake server, I mean scenarios like this. * I have web server in my company with or without passphrase access enabled called "www.example.com" * I have dynamic DNS enabled, as well, for laptops. * Some fool names their laptop "ww.example.com" in my local DNS, * The new admin at work, unaware of this "we don't allow PassPhrase based access", tries to log into "www.example.com". * The new admin uses his password. Having difficulty logging into the honeypot, he then tries to log in as root or other administrtive accounts. * The honeypoyt now has copies of the login names, and passphrases, stored in cleartext, without having to modify a single line of their OpenSSH source code or a single byte of their binary. * Voila: stashed passphrases and login names for the deired "www.example.com". The possibilities, individually, may not seem to be high. But there are so very many potential ways to abuse this it seems extremely wise to enable at all, much less as a built-in feature. From ronf at timeheart.net Mon Dec 19 05:07:10 2016 From: ronf at timeheart.net (Ron Frederick) Date: Sun, 18 Dec 2016 10:07:10 -0800 Subject: Working X11 with macOS In-Reply-To: <4D04D343-8CB3-4CBD-A800-C89C3A1694A2@kirei.se> References: <20161214195801.18280523.8231.106777@ll.mit.edu> <4D04D343-8CB3-4CBD-A800-C89C3A1694A2@kirei.se> Message-ID: <1AABF675-E9DC-40B8-AEC5-E91B82CC967D@timeheart.net> On Dec 15, 2016, at 4:38 AM, Jakob Schlyter wrote: > On 2016-12-15 at 01:05, Darren Tucker wrote: > >> On Thu, Dec 15, 2016 at 6:58 AM, Blumenthal, Uri - 0553 - MITLL >> wrote: >> [OSX launchd diff] >>> I for one would like to see it merged. >> >> I took the patch and addressed the comments in >> https://bugzilla.mindrot.org/show_bug.cgi?id=2341. If we can get some >> confirmation that it >> (https://bugzilla.mindrot.org/attachment.cgi?id=2915&action=edit) >> works OK we might be able to get that in. > > People running macOS, please test this patch by doing X11 forwarding with macOS client to any server. To get current code easiser, use branch 'osx' from repo https://github.com/jschlyter/openssh-portable.git. Looking at this patch, it seems to me that it introduces a possible exploit. The new code calls stat() on whatever string is set as the display value, even before checking for display values that are meant to refer to remote network hosts. If ?ssh? is run in a directory which happens to have a file/pipe/socket named to match one of those network display values, this new code would return that it should connect to this local socket rather than the remote host when doing the forwarding. While checking for ?/tmp/launch? as a prefix is a problem now that MacOS is putting these local sockets in paths starting with ?/private/tmp/com.apple.launchd?, I think this new code should at a minimum require that the path start with a leading ?/? before treating it as a local socket and doing a stat() on it. -- Ron Frederick ronf at timeheart.net From uri at ll.mit.edu Mon Dec 19 06:07:47 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 18 Dec 2016 19:07:47 +0000 Subject: Extend logging of openssh-server - e.g. plaintext password Message-ID: <20161218190756.18280523.7262.107305@ll.mit.edu> Also, if password-based auth is not allowed, WTF would you want to log passwords? This whole idea is ugly, and smacks of a teenage-level prank attempt. I would strongly object against any such modification of the main source (though I'm sure the maintainers are sane enough to never let such a crap in). Of course the original poster is free to hack his own copy in whatever way he wants.? P.S. This silliness underscores the value and timeliness of using? hardware tokens & PK-based authentication. :-) Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Nico Kadel-Garcia Sent: Sunday, December 18, 2016 12:56 To: Philipp Vlassakakis Cc: Blumenthal, Uri - 0553 - MITLL; openssh-unix-dev at mindrot.org Subject: Re: Extend logging of openssh-server - e.g. plaintext password On Sun, Dec 18, 2016 at 12:26 PM, Philipp Vlassakakis wrote: > Please accept my apologies. Sorry if my previous mails sound rude, it was not my intention. > > @Nico: > What do you mean with ?setting up a fake server? ? > Should I change my SSH-Port to a non-default port and install a SSH-Honeypot like Kippo, which listens on Port 22 as my ?SSH-Honeypot-Password-Harvester? ? > > With this solution i don?t have to modify the source code of the openssh-server-package. > > Regards, > Philipp ? By setting up a fake server, I mean scenarios like this. * I have web server in my company with or without passphrase access enabled called "www.example.com" * I have dynamic DNS enabled, as well, for laptops. * Some fool names their laptop "ww.example.com" in my local DNS, * The new admin at work, unaware of this "we don't allow PassPhrase based access", tries to log into "www.example.com". * The new admin uses his password. Having difficulty logging into the honeypot, he then tries to log in as root or other administrtive accounts. * The honeypoyt now has copies of the login names, and passphrases, stored in cleartext, without having to modify a single line of their OpenSSH source code or a single byte of their binary. * Voila: stashed passphrases and login names for the deired "www.example.com". The possibilities, individually, may not seem to be high. But there are so very many potential ways to abuse this it seems extremely wise to enable at all, much less as a built-in feature. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From alex at alex.org.uk Mon Dec 19 08:13:55 2016 From: alex at alex.org.uk (Alex Bligh) Date: Sun, 18 Dec 2016 21:13:55 +0000 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: <20161218190756.18280523.7262.107305@ll.mit.edu> References: <20161218190756.18280523.7262.107305@ll.mit.edu> Message-ID: > On 18 Dec 2016, at 19:07, Blumenthal, Uri - 0553 - MITLL wrote: > > Also, if password-based auth is not allowed, WTF would you want to log passwords? > > This whole idea is ugly, and smacks of a teenage-level prank attempt. > > I would strongly object against any such modification of the main source (though I'm sure the maintainers are sane enough to never let such a crap in). Am I missing something? OP asked for a means of modifying *his own* openssh to log passwords "only for his honeypots", and Stephen Harris replied telling him how to do it, having done this as a demonstration that password authentication is in general problematic (his blog article explains in essence that if he can do this, anyone else can do this, and you might ssh to their server by accident - let's ignore the unrecognised host key stuff). No one has suggested adding this to the main source code. Clearly that would be foolhardy. Is it really necessary to jump down people's throats for a reasonably phrased question, and an answer (with a reasonably well written blog article) behind it? -- Alex Bligh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From uri at ll.mit.edu Mon Dec 19 08:29:37 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 18 Dec 2016 21:29:37 +0000 Subject: Extend logging of openssh-server - e.g. plaintext password In-Reply-To: References: <20161218190756.18280523.7262.107305@ll.mit.edu> Message-ID: <20161218212946.18280523.24356.107319@ll.mit.edu> Depends on the question, and the potential (likely) consequences of the answer being implemented. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Alex Bligh Sent: Sunday, December 18, 2016 16:14 To: Blumenthal, Uri - 0553 - MITLL Cc: Alex Bligh; Nico Kadel-Garcia; Philipp Vlassakakis; openssh-unix-dev at mindrot.org Subject: Re: Extend logging of openssh-server - e.g. plaintext password > On 18 Dec 2016, at 19:07, Blumenthal, Uri - 0553 - MITLL wrote: > > Also, if password-based auth is not allowed, WTF would you want to log passwords? > > This whole idea is ugly, and smacks of a teenage-level prank attempt. > > I would strongly object against any such modification of the main source (though I'm sure the maintainers are sane enough to never let such a crap in). Am I missing something? OP asked for a means of modifying *his own* openssh to log passwords "only for his honeypots", and Stephen Harris replied telling him how to do it, having done this as a demonstration that password authentication is in general problematic (his blog article explains in essence that if he can do this, anyone else can do this, and you might ssh to their server by accident - let's ignore the unrecognised host key stuff). No one has suggested adding this to the main source code. Clearly that would be foolhardy. Is it really necessary to jump down people's throats for a reasonably phrased question, and an answer (with a reasonably well written blog article) behind it? -- Alex Bligh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From djm at mindrot.org Mon Dec 19 09:22:00 2016 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Dec 2016 09:22:00 +1100 (AEDT) Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: On Sun, 18 Dec 2016, Tom G. Christensen wrote: > On 14/12/16 01:53, Damien Miller wrote: > > Hi, > > > > OpenSSH 7.4 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. > > I've tested Solaris 2.6/sparc, 7/sparc, 8/sparc and 9/x86 using HEAD from the > git repo. > > All exhihit this error: > test_utf8: .. > regress/unittests/utf8/tests.c:52 test #3 "utf8_null" > ASSERT_STRING_EQ(buf, wants) failed: > buf = (NULL) (len zu) > wants = (null) (len zu) > gmake[1]: *** [unit] Error 134 Thanks for testing! It looks like that test case relies on undefined behaviour (printf of NULL). We should just disable it: diff --git a/regress/unittests/utf8/tests.c b/regress/unittests/utf8/tests.c index 6d06fa1..c2793ea 100644 --- a/regress/unittests/utf8/tests.c +++ b/regress/unittests/utf8/tests.c @@ -65,7 +65,6 @@ tests(void) TEST_DONE(); badarg(); - one("null", NULL, 8, 6, 6, "(null)"); one("empty", "", 2, 0, 0, ""); one("ascii", "x", -2, -2, -2, "x"); one("newline", "a\nb", -2, -2, -2, "a\nb"); From dfong at dfong.org Mon Dec 19 14:17:09 2016 From: dfong at dfong.org (Don Fong) Date: Sun, 18 Dec 2016 19:17:09 -0800 Subject: config file line length limit Message-ID: To all, i think i've found a minor bug in openssh. i'm writing to the list toget input on whether it's really a bug, or an undocumented limit, or maybe it's even documented somewhere (although i didn't see it documented in ssh_config(5)). if there is a consensus that this is indeed a bug, i'll file it in bugzilla. i would also like to submit the fix. the bug is that ssh barfs if my .ssh/config file contains a very long comment line. basically it tries to parse anything beyond the 1022-th char as regular input, not a comment. i discovered this behavior by accident. i have an ansible script that spins up new AWS instances. it creates an ssh config stanza for eachnew instance. at the start of the stanza, the script puts a commentline containing amazon's JSON description of the instance. dueto recent changes made by amazon, the description is longer than it used to be, making the comment longer. then ssh started failing. example (using the attached config file verylong.config): $ ssh -F verylong.config whatever verylong.config: line 9: Bad configuration option: ABCDEFG verylong.config: terminating, 1 bad configuration options i decided to take a look at the ssh source code. i think it is pretty clear what is going wrong. ----- readconf.c: 1703 char line[1024]; ... 1730 while (fgets(line, sizeof(line), f)) { 1731 /* Update line number counter. */ 1732 linenum++; 1733 if (process_config_line_depth(options, pw, host, original_host, 1734 line, filename, linenum, activep, flags, depth) != 0) 1735 bad_options++; 1736 } if fgets() runs across a very long input line, whatever won't fit in the given buffer (sizeof line) is left unread on the input stream, to be picked up by later reads. this is the documented behavior of fgets(). how long is too long? the buffer is sized at 1024 chars. one char is needed for the null terminator, another one for the newline. so anything longer than 1024-2 = 1022 bytes is too big. unf readconf.c as written just naively assumes that fgets() returns the entire line. it makes no attempt to deal with the case where the line didn't entirely fit. so basically, a long line is treated as multiple lines. this is true whether the line was a comment or something else. it's just that the behavior stands out more for a comment line, which "should" be completely ignored. besides, there's not much reason for any other type of line to be that long, in the config file. i see basically the same problem in the libopenssh version of readconf.c. IMHO this is a bug. some might consider it to be a reasonable limit on the line length, but in that case it should be documented in ssh_config(5). and in either case, i think line[] should be declared using a symbolic constant for the length. or, get rid of the fixed-length buffer, and implement a dynamically sized buffer instead. since i've only begun to look at this code, i'm not sure this would be a safe thing to do. is there any other code that implicitly assumes that the line length is less than 1024? incidentally, i see a strange discrepancy between the openssh-portable version and the libopenssh version. before the while-fgets loop, there is this comment (both versions): 1095 /* 1096 * Mark that we are now processing the options. This flag is turned 1097 * on/off by Host specifications. 1098 */ 1099 active = 1; but the "active=1" (line 1099) appears only in the libopenssh version, not the openssh-portable version. -------------- next part -------------- # 1 this is a very long comment line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxx # 2 this is a very long comment line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxx # 3 this is a very long comment line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxx # 4 this is a very long comment line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxx # 5 this is a longer comment line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxABCDEFG Host whatever Hostname localhost From djm at mindrot.org Mon Dec 19 14:52:16 2016 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Dec 2016 14:52:16 +1100 (AEDT) Subject: config file line length limit In-Reply-To: References: Message-ID: Hi, This does look like a bug, so it would be great if you could file it on bugzilla. Thanks, Damien On Sun, 18 Dec 2016, Don Fong wrote: > To all, > > i think i've found a minor bug in openssh. i'm writing to the list > toget input on whether it's really a bug, or an undocumented limit, > or maybe it's even documented somewhere (although i didn't see > it documented in ssh_config(5)). if there is a consensus that this > is indeed a bug, i'll file it in bugzilla. i would also like to > submit the fix. > > the bug is that ssh barfs if my .ssh/config file contains a very > long comment line. basically it tries to parse anything beyond > the 1022-th char as regular input, not a comment. > > i discovered this behavior by accident. i have an ansible script > that spins up new AWS instances. it creates an ssh config stanza > for eachnew instance. at the start of the stanza, the script puts > a commentline containing amazon's JSON description of the instance. > dueto recent changes made by amazon, the description is longer than > it used to be, making the comment longer. then ssh started failing. > > example (using the attached config file verylong.config): > > $ ssh -F verylong.config whatever > verylong.config: line 9: Bad configuration option: ABCDEFG > verylong.config: terminating, 1 bad configuration options > > i decided to take a look at the ssh source code. i think it is > pretty clear what is going wrong. > > ----- readconf.c: > 1703 char line[1024]; > ... > 1730 while (fgets(line, sizeof(line), f)) { > 1731 /* Update line number counter. */ > 1732 linenum++; > 1733 if (process_config_line_depth(options, pw, host, > original_host, > 1734 line, filename, linenum, activep, flags, depth) > != 0) > 1735 bad_options++; > 1736 } > > if fgets() runs across a very long input line, whatever won't fit in > the given buffer (sizeof line) is left unread on the input stream, > to be picked up by later reads. this is the documented behavior of > fgets(). how long is too long? the buffer is sized at 1024 chars. > one char is needed for the null terminator, another one for the > newline. so anything longer than 1024-2 = 1022 bytes is too big. > > unf readconf.c as written just naively assumes that fgets() returns the > entire line. it makes no attempt to deal with the case where the line > didn't entirely fit. so basically, a long line is treated as multiple > lines. this is true whether the line was a comment or something else. > it's just that the behavior stands out more for a comment line, which > "should" be completely ignored. besides, there's not much reason for > any other type of line to be that long, in the config file. > > i see basically the same problem in the libopenssh version of readconf.c. > > IMHO this is a bug. some might consider it to be a reasonable limit > on the line length, but in that case it should be documented in > ssh_config(5). and in either case, i think line[] should be declared > using a symbolic constant for the length. > > or, get rid of the fixed-length buffer, and implement a dynamically > sized buffer instead. since i've only begun to look at this code, > i'm not sure this would be a safe thing to do. is there any other > code that implicitly assumes that the line length is less than 1024? > > incidentally, i see a strange discrepancy between the openssh-portable > version and the libopenssh version. before the while-fgets loop, > there is this comment (both versions): > > 1095 /* > 1096 * Mark that we are now processing the options. This flag > is turned > 1097 * on/off by Host specifications. > 1098 */ > 1099 active = 1; > > but the "active=1" (line 1099) appears only in the libopenssh version, > not the openssh-portable version. > > > > > > > > From jakob at kirei.se Mon Dec 19 18:15:35 2016 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 19 Dec 2016 08:15:35 +0100 Subject: Working X11 with macOS In-Reply-To: <1AABF675-E9DC-40B8-AEC5-E91B82CC967D@timeheart.net> References: <20161214195801.18280523.8231.106777@ll.mit.edu> <4D04D343-8CB3-4CBD-A800-C89C3A1694A2@kirei.se> <1AABF675-E9DC-40B8-AEC5-E91B82CC967D@timeheart.net> Message-ID: On 2016-12-18 at 19:07, Ron Frederick wrote: > While checking for ?/tmp/launch? as a prefix is a problem now that > MacOS is putting these local sockets in paths starting with > ?/private/tmp/com.apple.launchd?, I think this new code should at > a minimum require that the path start with a leading ?/? before > treating it as a local socket and doing a stat() on it. Even though this may be to late for 7.4, here's a patch: https://github.com/jschlyter/openssh-portable/commit/874603571f4eb7aa1ff8ff7cc1222de7ee973bbb Do we want an error logged as well? jakob From masud.s.rahman at gmail.com Mon Dec 19 18:08:34 2016 From: masud.s.rahman at gmail.com (Masud Rahman) Date: Mon, 19 Dec 2016 02:08:34 -0500 Subject: Call for testing: OpenSSH 7.4 Message-ID: On 1 ?4? December 2016 at ?11? : ?53? , < ?djm? @mindrot.org> wrote: > Hi, > > OpenSSH 7.4 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/ or via a > mirror at Github: https://github.com/openssh/openssh-portable > > 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. Tested: * git commit 4a354fc2 ? from master of github's mirror of openssh-portable * on macOS Sierra using LibreSSL 2.4.4 Outcome: * successfully built * all tests passed Live testing: * connected to Linux amd64 host running sshd 7.3p1: * passphrase-protected ed25519 client key + certificate * ed25519 host key + certificate * chacha20-poly1305 cipher I note that clang (Apple LLVM version 8.0.0 (clang-800.0.42.1)) warned about the unused '-pie' flag supplied as a linker argument: clang: warning: argument unused during compilation: '-pie Summary output of the configure script is included at the end for reference (note that 'gcc' is an alias for 'clang' on this platform). Regards, Masud. OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: S/KEY support: no MD5 password support: no libedit support: no Solaris process contract support: no Solaris project support: no Solaris privilege support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Privsep sandbox style: darwin Host: x86_64-apple-darwin16.3.0 Compiler: gcc Compiler flags: -g -O2 -Qunused-arguments -Wunknown-warning-option -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-strong -fPIE Preprocessor flags: -I/usr/local/opt/libressl/include Linker flags: -L/usr/local/opt/libressl/lib -fstack-protector-strong -pie Libraries: -lcrypto -lz -lresolv +for sshd: -lsandbox From djm at openbsd.org Tue Dec 20 00:56:04 2016 From: djm at openbsd.org (Damien Miller) Date: Mon, 19 Dec 2016 06:56:04 -0700 (MST) Subject: Announce: OpenSSH 7.4 released Message-ID: <4ab69c9ee0fa45d1@openbsd.org> OpenSSH 7.4 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. OpenSSH also includes transitional support for the legacy SSH 1.3 and 1.5 protocols that may be enabled at compile-time. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Future deprecation notice ========================= We plan on retiring more legacy cryptography in future releases, specifically: * In approximately August 2017, removing remaining support for the SSH v.1 protocol (client-only and currently compile-time disabled). * In the same release, removing support for Blowfish and RC4 ciphers and the RIPE-MD160 HMAC. (These are currently run-time disabled). * Refusing all RSA keys smaller than 1024 bits (the current minimum is 768 bits) * The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled. * The next release of portable OpenSSH will remove support for OpenSSL version prior to 1.0.1. This list reflects our current intentions, but please check the final release notes for future releases. Potentially-incompatible changes ================================ This release includes a number of changes that may affect existing configurations: * This release removes server support for the SSH v.1 protocol. * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit block ciphers are not safe in 2016 and we don't want to wait until attacks like SWEET32 are extended to SSH. As 3des-cbc was the only mandatory cipher in the SSH RFCs, this may cause problems connecting to older devices using the default configuration, but it's highly likely that such devices already need explicit configuration for key exchange and hostkey algorithms already anyway. * sshd(8): Remove support for pre-authentication compression. Doing compression early in the protocol probably seemed reasonable in the 1990s, but today it's clearly a bad idea in terms of both cryptography (cf. multiple compression oracle attacks in TLS) and attack surface. Pre-auth compression support has been disabled by default for >10 years. Support remains in the client. * ssh-agent will refuse to load PKCS#11 modules outside a whitelist of trusted paths by default. The path whitelist may be specified at run-time. * sshd(8): When a forced-command appears in both a certificate and an authorized keys/principals command= restriction, sshd will now refuse to accept the certificate unless they are identical. The previous (documented) behaviour of having the certificate forced-command override the other could be a bit confusing and error-prone. * sshd(8): Remove the UseLogin configuration directive and support for having /bin/login manage login sessions. Changes since OpenSSH 7.3 ========================= This is primarily a bugfix release. Security -------- * ssh-agent(1): Will now refuse to load PKCS#11 modules from paths outside a trusted whitelist (run-time configurable). Requests to load modules could be passed via agent forwarding and an attacker could attempt to load a hostile PKCS#11 module across the forwarded agent channel: PKCS#11 modules are shared libraries, so this would result in code execution on the system running the ssh-agent if the attacker has control of the forwarded agent-socket (on the host running the sshd server) and the ability to write to the filesystem of the host running ssh-agent (usually the host running the ssh client). Reported by Jann Horn of Project Zero. * sshd(8): When privilege separation is disabled, forwarded Unix- domain sockets would be created by sshd(8) with the privileges of 'root' instead of the authenticated user. This release refuses Unix-domain socket forwarding when privilege separation is disabled (Privilege separation has been enabled by default for 14 years). Reported by Jann Horn of Project Zero. * sshd(8): Avoid theoretical leak of host private key material to privilege-separated child processes via realloc() when reading keys. No such leak was observed in practice for normal-sized keys, nor does a leak to the child processes directly expose key material to unprivileged users. Reported by Jann Horn of Project Zero. * sshd(8): The shared memory manager used by pre-authentication compression support had a bounds checks that could be elided by some optimising compilers. Additionally, this memory manager was incorrectly accessible when pre-authentication compression was disabled. This could potentially allow attacks against the privileged monitor process from the sandboxed privilege-separation process (a compromise of the latter would be required first). This release removes support for pre-authentication compression from sshd(8). Reported by Guido Vranken using the Stack unstable optimisation identification tool (http://css.csail.mit.edu/stack/) * sshd(8): Fix denial-of-service condition where an attacker who sends multiple KEXINIT messages may consume up to 128MB per connection. Reported by Shi Lei of Gear Team, Qihoo 360. * sshd(8): Validate address ranges for AllowUser and DenyUsers directives at configuration load time and refuse to accept invalid ones. It was previously possible to specify invalid CIDR address ranges (e.g. user at 127.1.2.3/55) and these would always match, possibly resulting in granting access where it was not intended. Reported by Laurence Parry. New Features ------------ * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the version in PuTTY by Simon Tatham. This allows a multiplexing client to communicate with the master process using a subset of the SSH packet and channels protocol over a Unix-domain socket, with the main process acting as a proxy that translates channel IDs, etc. This allows multiplexing mode to run on systems that lack file- descriptor passing (used by current multiplexing code) and potentially, in conjunction with Unix-domain socket forwarding, with the client and multiplexing master process on different machines. Multiplexing proxy mode may be invoked using "ssh -O proxy ..." * sshd(8): Add a sshd_config DisableForwaring option that disables X11, agent, TCP, tunnel and Unix domain socket forwarding, as well as anything else we might implement in the future. Like the 'restrict' authorized_keys flag, this is intended to be a simple and future-proof way of restricting an account. * sshd(8), ssh(1): Support the "curve25519-sha256" key exchange method. This is identical to the currently-supported method named "curve25519-sha256 at libssh.org". * sshd(8): Improve handling of SIGHUP by checking to see if sshd is already daemonised at startup and skipping the call to daemon(3) if it is. This ensures that a SIGHUP restart of sshd(8) will retain the same process-ID as the initial execution. sshd(8) will also now unlink the PidFile prior to SIGHUP restart and re-create it after a successful restart, rather than leaving a stale file in the case of a configuration error. bz#2641 * sshd(8): Allow ClientAliveInterval and ClientAliveCountMax directives to appear in sshd_config Match blocks. * sshd(8): Add %-escapes to AuthorizedPrincipalsCommand to match those supported by AuthorizedKeysCommand (key, key type, fingerprint, etc.) and a few more to provide access to the contents of the certificate being offered. * Added regression tests for string matching, address matching and string sanitisation functions. * Improved the key exchange fuzzer harness. Bugfixes -------- * ssh(1): Allow IdentityFile to successfully load and use certificates that have no corresponding bare public key. bz#2617 certificate id_rsa-cert.pub (and no id_rsa.pub). * ssh(1): Fix public key authentication when multiple authentication is in use and publickey is not just the first method attempted. bz#2642 * regress: Allow the PuTTY interop tests to run unattended. bz#2639 * ssh-agent(1), ssh(1): improve reporting when attempting to load keys from PKCS#11 tokens with fewer useless log messages and more detail in debug messages. bz#2610 * ssh(1): When tearing down ControlMaster connections, don't pollute stderr when LogLevel=quiet. * sftp(1): On ^Z wait for underlying ssh(1) to suspend before suspending sftp(1) to ensure that ssh(1) restores the terminal mode correctly if suspended during a password prompt. * ssh(1): Avoid busy-wait when ssh(1) is suspended during a password prompt. * ssh(1), sshd(8): Correctly report errors during sending of ext- info messages. * sshd(8): fix NULL-deref crash if sshd(8) received an out-of- sequence NEWKEYS message. * sshd(8): Correct list of supported signature algorithms sent in the server-sig-algs extension. bz#2547 * sshd(8): Fix sending ext_info message if privsep is disabled. * sshd(8): more strictly enforce the expected ordering of privilege separation monitor calls used for authentication and allow them only when their respective authentication methods are enabled in the configuration * sshd(8): Fix uninitialised optlen in getsockopt() call; harmless on Unix/BSD but potentially crashy on Cygwin. * Fix false positive reports caused by explicit_bzero(3) not being recognised as a memory initialiser when compiled with -fsanitize-memory. * sshd_config(5): Use 2001:db8::/32, the official IPv6 subnet for configuration examples. Portability ----------- * On environments configured with Turkish locales, fall back to the C/POSIX locale to avoid errors in configuration parsing caused by that locale's unique handling of the letters 'i' and 'I'. bz#2643 * sftp-server(8), ssh-agent(1): Deny ptrace on OS X using ptrace(PT_DENY_ATTACH, ..) * ssh(1), sshd(8): Unbreak AES-CTR ciphers on old (~0.9.8) OpenSSL. * Fix compilation for libcrypto compiled without RIPEMD160 support. * contrib: Add a gnome-ssh-askpass3 with GTK+3 support. bz#2640 * sshd(8): Improve PRNG reseeding across privilege separation and force libcrypto to obtain a high-quality seed before chroot or sandboxing. * All: Explicitly test for broken strnvis. NetBSD added an strnvis and unfortunately made it incompatible with the existing one in OpenBSD and Linux's libbsd (the former having existed for over ten years). Try to detect this mess, and assume the only safe option if we're cross compiling. Checksums: ========== - SHA1 (openssh-7.4.tar.gz) = 1e2073f95d5ead8f2814b4b6c0700bcd533c410f - SHA1 (openssh-7.4p1.tar.gz) = 2330bbf82ed08cf3ac70e0acf00186ef3eeb97e0 - SHA256 (openssh-7.4.tar.gz) = +GEXh7Xr2J87cq1uA97hF9e+3lfOQ2LKxXGdmFXREf0 - SHA256 (openssh-7.4p1.tar.gz) = Gx/EoU4gJCkxgZJO0khy5vLgYpPz6JJqN2uK7EgfGdE= Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available as RELEASE_KEY.asc from the mirror sites. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From jpbion at jfwest.com Tue Dec 20 01:13:46 2016 From: jpbion at jfwest.com (jpbion at jfwest.com) Date: Mon, 19 Dec 2016 06:13:46 -0800 Subject: Progress resolving OpenSSL 1.1.0 issues Message-ID: <5f0478bf7469d021ee3b23252cfec658@jfwest.com> I know it has been stated that OpenSSL 1.1.0 is a non-starter for OpenSSH until a better compatibility system is provided by OpenSSL, allowing a single code-base to support interacting with both OpenSSL 1.0.x and 1.1.x. I also know various people have provided patches to OpenSSH offering such support, but it also seems as if OpenSSH is waiting for something official. These patches offered to OpenSSH may have forced users of OpenSSH to move to OpenSSL 1.1.x - I haven't checked that out, and I know that would be a non-starter. But perhaps they did offer a compatibility layer. Finally, I also realize OpenSSH has to work with multiple different SSL providers, not just OpenSSL, and that OpenSSL has forced a whole slew of changes on its 'customers'. I worry about a deadlock, though. Does the OpenSSL team even know that the OpenSSH project will not move toward 1.1.0 support until it provides a simpler and official multi-version compatibility system? If there is no communication with them, it is unlikely they'll think of working on the compatibility system themselves (else it would have already been provided, because it's a rather obvious and important need.) Or is the OpenSSH team simply saying "until there is one, we won't support OpenSSL 1.1.0" - hoping it just happens - but not making effort to see that it does? OpenSSH is one of the more important SSL 'customers' The view of "nope; I won't code a custom compatibility system" may absolutely be the right thing to say and do. But do we even have OpenSSL's ear, to make sure what was said here was heard? Thanks! Joel From doctor at doctor.nl2k.ab.ca Tue Dec 20 03:04:22 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 19 Dec 2016 09:04:22 -0700 Subject: Progress resolving OpenSSL 1.1.0 issues In-Reply-To: <5f0478bf7469d021ee3b23252cfec658@jfwest.com> References: <5f0478bf7469d021ee3b23252cfec658@jfwest.com> Message-ID: <20161219160422.GA48483@doctor.nl2k.ab.ca> On Mon, Dec 19, 2016 at 06:13:46AM -0800, jpbion at jfwest.com wrote: > I know it has been stated that OpenSSL 1.1.0 is a non-starter for > OpenSSH until a better compatibility system is provided by OpenSSL, > allowing a single code-base to support interacting with both OpenSSL > 1.0.x and 1.1.x. > > I also know various people have provided patches to OpenSSH offering > such support, but it also seems as if OpenSSH is waiting for something > official. These patches offered to OpenSSH may have forced users of > OpenSSH to move to OpenSSL 1.1.x - I haven't checked that out, and I > know that would be a non-starter. But perhaps they did offer a > compatibility layer. > > Finally, I also realize OpenSSH has to work with multiple different SSL > providers, not just OpenSSL, and that OpenSSL has forced a whole slew of > changes on its 'customers'. > > I worry about a deadlock, though. Does the OpenSSL team even know that > the OpenSSH project will not move toward 1.1.0 support until it provides > a simpler and official multi-version compatibility system? If there is > no communication with them, it is unlikely they'll think of working on > the compatibility system themselves (else it would have already been > provided, because it's a rather obvious and important need.) Or is the > OpenSSH team simply saying "until there is one, we won't support OpenSSL > 1.1.0" - hoping it just happens - but not making effort to see that it > does? > > OpenSSH is one of the more important SSL 'customers' The view of "nope; > I won't code a custom compatibility system" may absolutely be the right > thing to say and do. But do we even have OpenSSL's ear, to make sure > what was said here was heard? > Openssl 1.1 backwards compatability to Openssl 1.0 will not ever happen. The best programmers can do is to program around openssl 1.1 + Openssl less than 1.0 and libressl. > Thanks! > Joel > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From jjelen at redhat.com Tue Dec 20 04:10:28 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 19 Dec 2016 18:10:28 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> Message-ID: <244ccd2d-d245-d8e1-492d-aaf88b37c57a@redhat.com> On 12/14/2016 10:09 AM, Jakub Jelen wrote: > On 12/14/2016 02:22 AM, The Doctor wrote: >> run test forwarding.sh ... >> failed copy of /bin/ls >> cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy >> corrupted copy of /bin/ls >> Exit request sent. >> failed local and remote forwarding >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/source/openssh-SNAP-20161214 > I see very similar failures with vanilla openssh snapshot on Fedora > 25. Should be quite fairly reproducible: > > # tar -xf openssh-SNAP-20161214.tar.gz && cd openssh && ./configure && > make tests > [...] > test connection multiplexing: forward > cmp: EOF on /root/openssh/regress/copy > ssh: corrupted copy of /root/openssh/regress/data > /root/openssh/regress/multiplex.sh: line 96: 18570 > Terminated $NC -N -Ul $OBJ/unix-1.fwd < ${DATA} > /dev/null > [...] > request remote forward failed > connect to remote forwarded path failed > test connection multiplexing: cmd exit > test connection multiplexing: cmd stop > failed connection multiplexing > Makefile:198: recipe for target 't-exec' failed > make[1]: *** [t-exec] Error 1 > make[1]: Leaving directory '/root/openssh/regress' > Makefile:568: recipe for target 'tests' failed > make: *** [tests] Error 2 > > I will have a look into that if I will have a minute today. Further investigation so far showed, that the multiplex is failing to create the remote port forward socket: mux_client_forward: forwarding request failed: remote port forwarding failed for listen path /root/openssh/regress/unix-3.fwd I see the same results with RHEL7, with different user, and also with the openssh-SNAP-20161220.tar.gz. I will see tomorrow. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From naddy at mips.inka.de Tue Dec 20 04:43:22 2016 From: naddy at mips.inka.de (Christian Weisgerber) Date: Mon, 19 Dec 2016 17:43:22 +0000 (UTC) Subject: Do people use HostbasedAuthentication? Message-ID: Do people actually use HostbasedAuthentication? It needs several steps to enable and generally seems quite arcane by now. I wonder if this is something that could be trimmed away... -- Christian "naddy" Weisgerber naddy at mips.inka.de From ronf at timeheart.net Tue Dec 20 04:55:58 2016 From: ronf at timeheart.net (Ron Frederick) Date: Mon, 19 Dec 2016 09:55:58 -0800 Subject: Working X11 with macOS In-Reply-To: References: <20161214195801.18280523.8231.106777@ll.mit.edu> <4D04D343-8CB3-4CBD-A800-C89C3A1694A2@kirei.se> <1AABF675-E9DC-40B8-AEC5-E91B82CC967D@timeheart.net> Message-ID: <0F2010D3-0F8B-4685-A246-F0BD3335B0DF@timeheart.net> On Dec 18, 2016, at 11:15 PM, Jakob Schlyter wrote: > On 2016-12-18 at 19:07, Ron Frederick wrote: > >> While checking for ?/tmp/launch? as a prefix is a problem now that MacOS is putting these local sockets in paths starting with ?/private/tmp/com.apple.launchd?, I think this new code should at a minimum require that the path start with a leading ?/? before treating it as a local socket and doing a stat() on it. > > Even though this may be to late for 7.4, here's a patch: > > https://github.com/jschlyter/openssh-portable/commit/874603571f4eb7aa1ff8ff7cc1222de7ee973bbb > > Do we want an error logged as well? Thanks, Jakob - that patch looks good to me. I don?t think an error makes sense here. Anything not starting with a ?/? would get handled as if it were a hostname (or one of the other special cases like ?unix?), and there should already be error reporting in those places. -- Ron Frederick ronf at timeheart.net From dfong at dfong.org Tue Dec 20 04:59:43 2016 From: dfong at dfong.org (Don Fong) Date: Mon, 19 Dec 2016 09:59:43 -0800 Subject: config file line length limit In-Reply-To: References: Message-ID: Damien, thanks for your answer. any comments on ancillary issues? * should the limit be documented, or removed? or should the limit just be increased? * is there any mechanism to keep the code in libopenssh in sync with the corresponding code in openssh-portable? i would think that as a philosophical matter, openssh-portable should be using the same code as libopenssh where possible. particularly for things like readconf.c . (in fact, as a newcomer to this project, i am wondering why openssh-portable couldn't simply link in libopenssh as a library? why are they two separate github repos, instead of one repo that can build both the executable and the library?) * is there a missing assignment to active (*activep) in the openssh version of readconf.c, is the comment incorrect, or? On 12/18/16 19:52, Damien Miller wrote: > Hi, > > This does look like a bug, so it would be great if you could file it on > bugzilla. > > Thanks, > Damien > > On Sun, 18 Dec 2016, Don Fong wrote: > >> To all, >> >> i think i've found a minor bug in openssh. i'm writing to the list >> toget input on whether it's really a bug, or an undocumented limit, >> or maybe it's even documented somewhere (although i didn't see >> it documented in ssh_config(5)). if there is a consensus that this >> is indeed a bug, i'll file it in bugzilla. i would also like to >> submit the fix. >> >> the bug is that ssh barfs if my .ssh/config file contains a very >> long comment line. basically it tries to parse anything beyond >> the 1022-th char as regular input, not a comment. >> >> i discovered this behavior by accident. i have an ansible script >> that spins up new AWS instances. it creates an ssh config stanza >> for eachnew instance. at the start of the stanza, the script puts >> a commentline containing amazon's JSON description of the instance. >> dueto recent changes made by amazon, the description is longer than >> it used to be, making the comment longer. then ssh started failing. >> >> example (using the attached config file verylong.config): >> >> $ ssh -F verylong.config whatever >> verylong.config: line 9: Bad configuration option: ABCDEFG >> verylong.config: terminating, 1 bad configuration options >> >> i decided to take a look at the ssh source code. i think it is >> pretty clear what is going wrong. >> >> ----- readconf.c: >> 1703 char line[1024]; >> ... >> 1730 while (fgets(line, sizeof(line), f)) { >> 1731 /* Update line number counter. */ >> 1732 linenum++; >> 1733 if (process_config_line_depth(options, pw, host, >> original_host, >> 1734 line, filename, linenum, activep, flags, depth) >> != 0) >> 1735 bad_options++; >> 1736 } >> >> if fgets() runs across a very long input line, whatever won't fit in >> the given buffer (sizeof line) is left unread on the input stream, >> to be picked up by later reads. this is the documented behavior of >> fgets(). how long is too long? the buffer is sized at 1024 chars. >> one char is needed for the null terminator, another one for the >> newline. so anything longer than 1024-2 = 1022 bytes is too big. >> >> unf readconf.c as written just naively assumes that fgets() returns the >> entire line. it makes no attempt to deal with the case where the line >> didn't entirely fit. so basically, a long line is treated as multiple >> lines. this is true whether the line was a comment or something else. >> it's just that the behavior stands out more for a comment line, which >> "should" be completely ignored. besides, there's not much reason for >> any other type of line to be that long, in the config file. >> >> i see basically the same problem in the libopenssh version of readconf.c. >> >> IMHO this is a bug. some might consider it to be a reasonable limit >> on the line length, but in that case it should be documented in >> ssh_config(5). and in either case, i think line[] should be declared >> using a symbolic constant for the length. >> >> or, get rid of the fixed-length buffer, and implement a dynamically >> sized buffer instead. since i've only begun to look at this code, >> i'm not sure this would be a safe thing to do. is there any other >> code that implicitly assumes that the line length is less than 1024? >> >> incidentally, i see a strange discrepancy between the openssh-portable >> version and the libopenssh version. before the while-fgets loop, >> there is this comment (both versions): >> >> 1095 /* >> 1096 * Mark that we are now processing the options. This flag >> is turned >> 1097 * on/off by Host specifications. >> 1098 */ >> 1099 active = 1; >> >> but the "active=1" (line 1099) appears only in the libopenssh version, >> not the openssh-portable version. >> >> >> >> >> >> >> >> From gert at greenie.muc.de Tue Dec 20 05:18:23 2016 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 19 Dec 2016 19:18:23 +0100 Subject: Do people use HostbasedAuthentication? In-Reply-To: References: Message-ID: <20161219181823.GJ78624@greenie.muc.de> Hi, On Mon, Dec 19, 2016 at 05:43:22PM +0000, Christian Weisgerber wrote: > Do people actually use HostbasedAuthentication? It needs several > steps to enable and generally seems quite arcane by now. I wonder > if this is something that could be trimmed away... We use it. 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 tim at multitalents.net Tue Dec 20 06:00:41 2016 From: tim at multitalents.net (Tim Rice) Date: Mon, 19 Dec 2016 11:00:41 -0800 (PST) Subject: Do people use HostbasedAuthentication? In-Reply-To: References: Message-ID: On Mon, 19 Dec 2016, Christian Weisgerber wrote: > Do people actually use HostbasedAuthentication? It needs several > steps to enable and generally seems quite arcane by now. I wonder > if this is something that could be trimmed away... I use it a lot. -- Tim Rice Multitalents tim at multitalents.net From scott_n at xypro.com Tue Dec 20 06:32:46 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 19 Dec 2016 19:32:46 +0000 Subject: config file line length limit In-Reply-To: References: Message-ID: -----Original Message----- Don Fong, Monday, December 19, 2016 10:00 AM Damien, thanks for your answer. any comments on ancillary issues? * should the limit be documented, or removed? or should the limit just be increased? SAN> There's a third option. If the line is found to be longer than 1022 (1024?) characters, it should be flagged as an error in the config file. This is in conjunction with the documentation option. while (fgets(line, sizeof(line), f)) { /* NEW */ if (line[strlen(line)-1] != '\n') generate-an-error(); /* Update line number counter. */ linenum++; if (process_config_line_depth(options, pw, host, original_host, line, filename, linenum, activep, flags, depth) >> != 0) bad_options++; From djm at mindrot.org Tue Dec 20 09:01:24 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Dec 2016 09:01:24 +1100 (AEDT) Subject: Do people use HostbasedAuthentication? In-Reply-To: References: Message-ID: On Mon, 19 Dec 2016, Tim Rice wrote: > On Mon, 19 Dec 2016, Christian Weisgerber wrote: > > > Do people actually use HostbasedAuthentication? It needs several > > steps to enable and generally seems quite arcane by now. I wonder > > if this is something that could be trimmed away... > > I use it a lot. I use it so that it gets tested regularly and doesn't break :) From vapier at gentoo.org Tue Dec 20 07:59:35 2016 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 19 Dec 2016 15:59:35 -0500 Subject: [PATCH] regress/allow-deny-users.sh: fix bashism in test Message-ID: <20161219205935.29687-1-vapier@gentoo.org> The test command uses = for string compares, not ==. Using some POSIX shells will reject this statement with an error about an unknown operator. --- regress/allow-deny-users.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/regress/allow-deny-users.sh b/regress/allow-deny-users.sh index 32a269afa97c..86805e19322b 100644 --- a/regress/allow-deny-users.sh +++ b/regress/allow-deny-users.sh @@ -4,7 +4,7 @@ tid="AllowUsers/DenyUsers" me="$LOGNAME" -if [ "x$me" == "x" ]; then +if [ "x$me" = "x" ]; then me=`whoami` fi other="nobody" -- 2.11.0.rc2 From djm at mindrot.org Tue Dec 20 09:35:42 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Dec 2016 09:35:42 +1100 (AEDT) Subject: [PATCH] regress/allow-deny-users.sh: fix bashism in test In-Reply-To: <20161219205935.29687-1-vapier@gentoo.org> References: <20161219205935.29687-1-vapier@gentoo.org> Message-ID: applied - thanks On Mon, 19 Dec 2016, Mike Frysinger wrote: > The test command uses = for string compares, not ==. Using some POSIX > shells will reject this statement with an error about an unknown operator. > --- > regress/allow-deny-users.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/regress/allow-deny-users.sh b/regress/allow-deny-users.sh > index 32a269afa97c..86805e19322b 100644 > --- a/regress/allow-deny-users.sh > +++ b/regress/allow-deny-users.sh > @@ -4,7 +4,7 @@ > tid="AllowUsers/DenyUsers" > > me="$LOGNAME" > -if [ "x$me" == "x" ]; then > +if [ "x$me" = "x" ]; then > me=`whoami` > fi > other="nobody" > -- > 2.11.0.rc2 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From reini.urban at gmail.com Tue Dec 20 01:57:08 2016 From: reini.urban at gmail.com (Reini Urban) Date: Mon, 19 Dec 2016 15:57:08 +0100 Subject: typo in 7.4 announcement Message-ID: <757CC45A-12AD-4900-AA61-D1FD650841C8@gmail.com> https://www.openssh.com/txt/release-7.4 < sshd_config DisableForwaring > sshd_config DisableForwarding Reini Urban rurban at cpan.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From haruyama at unixuser.org Tue Dec 20 11:33:09 2016 From: haruyama at unixuser.org (HARUYAMA Seigo) Date: Tue, 20 Dec 2016 09:33:09 +0900 Subject: Tiny fix for INSTALL document Message-ID: <87inqfqw1m.wl-haruyama@unixuser.org> I found 2 mistakes in INSTALL document. diff --git a/INSTALL b/INSTALL index 6bc80b68..92106bf0 100644 --- a/INSTALL +++ b/INSTALL @@ -1,3 +1,4 @@ +1. Prerequisites ---------------- A C compiler. Any C89 or better compiler should work. Where supported, @@ -231,7 +232,7 @@ manually using the following commands: ssh-keygen -t [type] -f /etc/ssh/ssh_host_key -N "" -for each of the types you wish to generate (rsa, dsa or ecdsaa) or +for each of the types you wish to generate (rsa, dsa or ecdsa) or ssh-keygen -A From dtucker at zip.com.au Tue Dec 20 12:17:30 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Dec 2016 12:17:30 +1100 Subject: Tiny fix for INSTALL document In-Reply-To: <87inqfqw1m.wl-haruyama@unixuser.org> References: <87inqfqw1m.wl-haruyama@unixuser.org> Message-ID: Applied, thanks. On Tue, Dec 20, 2016 at 11:33 AM, HARUYAMA Seigo wrote: > I found 2 mistakes in INSTALL document. > > diff --git a/INSTALL b/INSTALL > index 6bc80b68..92106bf0 100644 > --- a/INSTALL > +++ b/INSTALL > @@ -1,3 +1,4 @@ > +1. Prerequisites > ---------------- > > A C compiler. Any C89 or better compiler should work. Where supported, > @@ -231,7 +232,7 @@ manually using the following commands: > > ssh-keygen -t [type] -f /etc/ssh/ssh_host_key -N "" > > -for each of the types you wish to generate (rsa, dsa or ecdsaa) or > +for each of the types you wish to generate (rsa, dsa or ecdsa) or > > ssh-keygen -A > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Dec 20 13:08:20 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Dec 2016 13:08:20 +1100 Subject: typo in 7.4 announcement In-Reply-To: <757CC45A-12AD-4900-AA61-D1FD650841C8@gmail.com> References: <757CC45A-12AD-4900-AA61-D1FD650841C8@gmail.com> Message-ID: On Tue, Dec 20, 2016 at 1:57 AM, Reini Urban wrote: > https://www.openssh.com/txt/release-7.4 > > < sshd_config DisableForwaring >> sshd_config DisableForwarding Fixed, thanks. Update should hit the web site shortly. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From abhi.dhiman83 at gmail.com Tue Dec 20 18:00:10 2016 From: abhi.dhiman83 at gmail.com (abhi dhiman) Date: Tue, 20 Dec 2016 12:30:10 +0530 Subject: Need Help to Fix CVE-2016-6210 Message-ID: Hi All, Actually I am working with the OpenSSH version 6.2p which is vulnerable to above mentioned vulnerabilities (CVE-2016-6210). 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 dtucker at zip.com.au Tue Dec 20 18:11:20 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Dec 2016 18:11:20 +1100 Subject: Need Help to Fix CVE-2016-6210 In-Reply-To: References: Message-ID: See https://anongit.mindrot.org/openssh.git/commit/?id=283b97ff33ea2c641161950849931bd578de6946 and https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b5e50692739d314cd8d9dc On Tue, Dec 20, 2016 at 6:00 PM, abhi dhiman wrote: > Hi All, > > Actually I am working with the OpenSSH version 6.2p which is vulnerable to > above mentioned vulnerabilities (CVE-2016-6210). > > 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 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Dec 20 18:21:18 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Dec 2016 18:21:18 +1100 Subject: Need Help to Fix CVE-2016-6210 In-Reply-To: References: Message-ID: On Tue, Dec 20, 2016 at 6:11 PM, Darren Tucker wrote: > See https://anongit.mindrot.org/openssh.git/commit/?id=283b97ff33ea2c641161950849931bd578de6946 > and https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b5e50692739d314cd8d9dc Also https://anongit.mindrot.org/openssh.git/commit/?id=dbf788b4d9d9490a5fff08a7b09888272bb10fcc if it's possible that your root accounts do not have valid password strings. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jjelen at redhat.com Tue Dec 20 19:39:26 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 20 Dec 2016 09:39:26 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: <244ccd2d-d245-d8e1-492d-aaf88b37c57a@redhat.com> References: <20161214010925.GA75127@doctor.nl2k.ab.ca> <20161214012241.GA84711@doctor.nl2k.ab.ca> <7105282d-6ac9-dada-d112-8e002c61fa5a@redhat.com> <244ccd2d-d245-d8e1-492d-aaf88b37c57a@redhat.com> Message-ID: On 12/19/2016 06:10 PM, Jakub Jelen wrote: > On 12/14/2016 10:09 AM, Jakub Jelen wrote: >> On 12/14/2016 02:22 AM, The Doctor wrote: >>> run test forwarding.sh ... >>> failed copy of /bin/ls >>> cmp: EOF on /usr/source/openssh-SNAP-20161214/regress/copy >>> corrupted copy of /bin/ls >>> Exit request sent. >>> failed local and remote forwarding >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/source/openssh-SNAP-20161214/regress >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/source/openssh-SNAP-20161214 >> I see very similar failures with vanilla openssh snapshot on Fedora >> 25. Should be quite fairly reproducible: >> >> # tar -xf openssh-SNAP-20161214.tar.gz && cd openssh && ./configure >> && make tests >> [...] >> test connection multiplexing: forward >> cmp: EOF on /root/openssh/regress/copy >> ssh: corrupted copy of /root/openssh/regress/data >> /root/openssh/regress/multiplex.sh: line 96: 18570 >> Terminated $NC -N -Ul $OBJ/unix-1.fwd < ${DATA} > /dev/null >> [...] >> request remote forward failed >> connect to remote forwarded path failed >> test connection multiplexing: cmd exit >> test connection multiplexing: cmd stop >> failed connection multiplexing >> Makefile:198: recipe for target 't-exec' failed >> make[1]: *** [t-exec] Error 1 >> make[1]: Leaving directory '/root/openssh/regress' >> Makefile:568: recipe for target 'tests' failed >> make: *** [tests] Error 2 >> >> I will have a look into that if I will have a minute today. > Further investigation so far showed, that the multiplex is failing to > create the remote port forward socket: > > mux_client_forward: forwarding request failed: remote port forwarding > failed for listen path /root/openssh/regress/unix-3.fwd This is obviously related to the commit (fix for CVE-2016-10010): https://github.com/openssh/openssh-portable/commit/b737e4 preventing running the multiplex.sh test (remote port forwarding is failing) with root permissions (stops using privilege separation at https://github.com/openssh/openssh-portable/blob/master/sshd.c#L640 Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From hecht at hlrs.de Tue Dec 20 20:00:04 2016 From: hecht at hlrs.de (Martin Hecht) Date: Tue, 20 Dec 2016 10:00:04 +0100 Subject: Do people use HostbasedAuthentication? In-Reply-To: References: Message-ID: <299f7617-9c67-24ae-bb2c-a4bf10521570@hlrs.de> On 12/19/2016 06:43 PM, Christian Weisgerber wrote: > Do people actually use HostbasedAuthentication? It needs several > steps to enable and generally seems quite arcane by now. I wonder > if this is something that could be trimmed away... > we are using it on the internal network of our clusters, where we have control over all the hosts. Once configured for the hosts it avoids the need for managing authorized_keys for each user. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5254 bytes Desc: S/MIME Cryptographic Signature URL: From imorgan at nas.nasa.gov Wed Dec 21 05:46:59 2016 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 20 Dec 2016 10:46:59 -0800 Subject: Do people use HostbasedAuthentication? In-Reply-To: References: Message-ID: <20161220184659.GA7106@linux124.nas.nasa.gov> On Mon, Dec 19, 2016 at 11:00:41 -0800, Tim Rice wrote: > On Mon, 19 Dec 2016, Christian Weisgerber wrote: > > > Do people actually use HostbasedAuthentication? It needs several > > steps to enable and generally seems quite arcane by now. I wonder > > if this is something that could be trimmed away... > > I use it a lot. > In large clustered environments that do not use GSSAPI, it is important. -- Iain Morgan From gheskett at shentel.net Wed Dec 21 07:15:01 2016 From: gheskett at shentel.net (Gene Heskett) Date: Tue, 20 Dec 2016 15:15:01 -0500 Subject: Do people use HostbasedAuthentication? In-Reply-To: <20161220184659.GA7106@linux124.nas.nasa.gov> References: <20161220184659.GA7106@linux124.nas.nasa.gov> Message-ID: <201612201515.01667.gheskett@shentel.net> On Tuesday 20 December 2016 13:46:59 Iain Morgan wrote: > On Mon, Dec 19, 2016 at 11:00:41 -0800, Tim Rice wrote: > > On Mon, 19 Dec 2016, Christian Weisgerber wrote: > > > Do people actually use HostbasedAuthentication? It needs several > > > steps to enable and generally seems quite arcane by now. I wonder > > > if this is something that could be trimmed away... > > > > I use it a lot. > > In large clustered environments that do not use GSSAPI, it is > important. I use it everywhere on my home network, which is behind an uptodate install of dd-wrt. So yes, I use it a lot. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page From ilf at zeromail.org Thu Dec 22 02:18:27 2016 From: ilf at zeromail.org (ilf) Date: Wed, 21 Dec 2016 16:18:27 +0100 Subject: 7.4: DisableForwaring and Compression in man-pages In-Reply-To: <4ab69c9c89544aa9@openbsd.org> References: <4ab69c9c89544aa9@openbsd.org> Message-ID: <20161221151827.GY1072@zeromail.org> Thanks for OpenSSH 7.4! Damien Miller: > * sshd(8): Add a sshd_config DisableForwaring option that disables > X11, agent, TCP, tunnel and Unix domain socket forwarding, as well > as anything else we might implement in the future. Like the > 'restrict' authorized_keys flag, this is intended to be a simple > and future-proof way of restricting an account. Nice. But I cannot find this mentioned in man sshd_config.5? > * sshd(8): Remove support for pre-authentication compression. > Doing compression early in the protocol probably seemed reasonable > in the 1990s, but today it's clearly a bad idea in terms of both > cryptography (cf. multiple compression oracle attacks in TLS) and > attack surface. Pre-auth compression support has been disabled by > default for >10 years. Support remains in the client. Reading up on Compression, sshd_config.5 sais: > Specifies whether compression is enabled after the user has > authenticated successfully. The argument must be yes, delayed (a > legacy synonym for yes) or no. The default is yes. While ssh_config.5 sais: > Specifies whether to use compression. The argument must be yes or no > (the default). 1. Why does ssh_config.5 not say that this is post-authentication-compression? 2. Why is the default "yes" in sshd_config.5 and "no" in ssh_config.5? Thanks, and keep up the good work! -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From beebe at math.utah.edu Thu Dec 22 09:00:13 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 21 Dec 2016 15:00:13 -0700 Subject: Successful builds report for openssh-SNAP-20161221 Message-ID: Yesterday, after seeing and hearing a note about the need for more OpenSSH testing in the most recent episode of BSD Now TV at http://www.bsdnow.tv/episodes/2016_12_14_a_tale_of_bsd_from_yore I fetched the latest snapshot (openssh-SNAP-20161221) from http://www.mindrot.org/openssh_snap/ repackaged it as openssh-20161221.tar.xz (so the basename of the .tar.* file matches the directory into which it unpacks: please consider making a similar change at your end), and started automated builds in our test lab of 125+ flavors of Unix(-like) systems. I've gone through the logs today, and found that 55 builds reported "all tests passed": the successes were on these systems (CPUs are x86-64, unless otherwise noted in parentheses): ArchLinux CentOS 5.11 CentOS 5.11 (IA-64 (Itanium)) CentOS 5.11 (x86) CentOS 6.8 CentOS 7.3 DragonFlyBSD 3.8 DragonFlyBSD 3.9 DragonFlyBSD 4.0 DragonFlyBSD 4.2 DragonFlyBSD 4.4 Dragora 2.2 Fedora 23 FreeBSD 10 FreeBSD 11 FreeBSD 12 Gentoo GhostBSD 10 HardenedBSD 11 Hipster Kali 1.1.0 Kali rolling 2016.1 Knoppix 7.6.0 LibertyBSD 5.9 Mageia 5 MidnightBSD 0.7 MidnightBSD 0.8 NetBSD 5.0.2 NetBSD 7.0.2 OmniOS 11 OpenBSD 4.9 OpenBSD 5.9 OpenBSD 6.0 OpenIndiana 11 Oracle 7.3 PCBSD 10.3 PCLinuxOS release 2016 PacBSD 11.0-BETA1 Slackware 14.2 Solaris 10 Solaris 10 (SPARC) Solaris 10 (x86) Solaris 11.3 Solus 1.2.0.5 Tribblix 0.18 TrueOS (FreeBSD 12 relative) Ubuntu 16.04 LTS When no O/S version numbers are listed, the O/S uses a versionless rolling release model. All systems in the test lab are kept up to current software packages releases, usually at least twice a month. In many of those, there are other versions of the O/S in our lab, some on different CPUs (we have at least ARM, Itanium, MIPS 5K and 10K, PowerPC, SPARC, x86, and x86-64) and I'm now about to investigate why their builds of openssh-20161221 were not entirely successful. Further build reports from me to this list may therefore follow. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From djm at mindrot.org Thu Dec 22 15:22:51 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 22 Dec 2016 15:22:51 +1100 (AEDT) Subject: 7.4: DisableForwaring and Compression in man-pages In-Reply-To: <20161221151827.GY1072@zeromail.org> References: <4ab69c9c89544aa9@openbsd.org> <20161221151827.GY1072@zeromail.org> Message-ID: On Wed, 21 Dec 2016, ilf wrote: > Thanks for OpenSSH 7.4! > > Damien Miller: > > * sshd(8): Add a sshd_config DisableForwaring option that disables X11, > > agent, TCP, tunnel and Unix domain socket forwarding, as well as anything > > else we might implement in the future. Like the 'restrict' authorized_keys > > flag, this is intended to be a simple and future-proof way of restricting > > an account. > > Nice. But I cannot find this mentioned in man sshd_config.5? It's there: [djm at haru openssh]$ grep -A5 DisableForwarding sshd_config.5 .It Cm DisableForwarding Disables all forwarding features, including X11, .Xr ssh-agent 1 , TCP and StreamLocal. This option overrides all other forwarding-related options and may simplify restricted configurations. > While ssh_config.5 sais: > > > Specifies whether to use compression. The argument must be yes or no (the > > default). > > 1. Why does ssh_config.5 not say that this is post-authentication-compression? Because on the client supports both, preferring delayed compression if possible. > 2. Why is the default "yes" in sshd_config.5 and "no" in ssh_config.5? In the SSH protocol, the client chooses connection options (cipher, compression, etc) from the sets of options that the server offers, so The option in sshd_config makes compression available for the client to use, and the option in the client says to use it if available. -d From beebe at math.utah.edu Fri Dec 23 04:44:09 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 22 Dec 2016 10:44:09 -0700 Subject: Failing builds report for openssh-SNAP-20161221 Message-ID: I reported yesterday on this list about 55 successful builds for openssh-SNAP-20161221 (repackaged locally as openssh-20161221) in our test lab of 125+ Unix(-like) systems. Today, I've gone through the 68 logs of failures. If a single long-time openssh developer wants to look at those logs in detail, please contact me offline; the logs contain machine details that I will not disclose on public lists. Here, I'll just summarize the common problems that appear repeatedly across many different systems. Fixing any single one of them would likely lead to successful builds on several more systems. -------------------------------------------------------------------------------- (1) The test suite output needs to be revised to show clear indications of success and failure; with just one log to look at, which most developers likely have, the current situation is somewhat tolerable. However, with large-scale automated testing, as I'm doing, it is impractical to read hundreds of lines of dense test output in logs from each of 125+ systems. [I just ran "wc -l" on the 157 logs that I have so far: 252,552 lines, equivalent to about 16 detective novels of 300 pages of 50 lines/page.] Many GNU packages have adopted a validation-suite output style that prefixes test names with "PASS" or "FAIL", followed by a summary of counts of passes and failures. Some even report a lovely conclusion "ALL TESTS PASSED!", which is then easy to grep for in logs to identify successful builds and validations. The current openssh report of "all tests passed" at the end of a log is hard to spot by eye, though grep, of course, has no difficulty. -------------------------------------------------------------------------------- (2) Please consider adding a Makefile "check" target equivalent to your "tests" target; the former is a GNU standard that is widely adopted by thousands of other open-source packages. That way, the standard recipe ./configure && make all check install could work almost everywhere. -------------------------------------------------------------------------------- (3) Wrong macro argument count: /usr/bin/cc -std=c99 -I/usr/uumath/include -I/usr/local/include -I/include -Qunused-arguments -Wunknown-warning-option -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 -I. -I.. -I. -I./.. -I/include -DHAVE_CONFIG_H -c arc4random.c In file included from arc4random.c:27: In file included from ../includes.h:174: In file included from ../entropy.h:28: In file included from ../buffer.h:24: In file included from ../sshbuf.h:23: /usr/include/stdio.h:222:44: error: too many arguments provided to function-like macro invocation __attribute__((__bounded__ (__size__,1,3,2))); ^ ../defines.h:519:10: note: macro '__bounded__' defined here # define __bounded__(x, y, z) -------------------------------------------------------------------------------- (4) openssh macro expands to invalid code: /usr/uumath/ashare/sys/developerstudio12.5/bin/cc -I/usr/uumath/include -I/include -I. -I.. -I. -I./.. -I/include -DHAVE_CONFIG_H -c arc4random.c "/usr/include/iso/stdlib_iso.h", line 130: syntax error before or at: 1 cc: acomp failed for arc4random.c That comes from the expansion of this line in that system header file: extern int mblen(const char *, size_t); The erroneous code extern int ( 1 ); is produced by this openssh code: % grep -n mblen openbsd-compat.h 230:# define mblen(x, y) (1) -------------------------------------------------------------------------------- (5) Several systems reported checking OpenSSL library version... configure: error: OpenSSL >= 0.9.8f required (have "0090802f (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008)") or checking whether OpenSSL's headers match the library... no configure: error: Your OpenSSL headers do not match your library. Check config.log for details. If you are sure your installation is consistent, you can disable the check by running "./configure --without-openssl-header-check". Also see contrib/findssl.sh for help identifying header/library mismatches. I don't propose to install openssl on our test lab machines, because we generally expect them to have their own ssh + ssl code in place already. Thus, I won't attempt to work around build problems from such dependencies. -------------------------------------------------------------------------------- (6) On KFreeBSD 7.5 x86-64, ArchLinux ARM, Debian 6.0.10 x86-64, DragonFlyBSD 4.6, 4.6.1, 4.7 x86-46, and Solaris 10 x86-64, I was able to get a successful build by adding the configure option --without-openssl-header-check. I then ran "make tests"; only the Solaris 10 x86-64 build ended with "all tests passed". The ARM run is still a long ways from completion as I finish this report. -------------------------------------------------------------------------------- (7) On numerous systems, I get these compilation failures: /usr/bin/cc -I/usr/uumath/include -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE -I. -I. -I/usr/uumath/include -DSSHDIR=\"/usr/uumath/etc\" -D_PATH_SSH_PROGRAM=\"/usr/uumath/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/uumath/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/uumath/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/uumath/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/uumath/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c sshkey.c -o sshkey.o sshkey.c:274:28: error: dereferencing pointer to incomplete type return BN_num_bits(k->rsa->n); ^ sshkey.c:277:28: error: dereferencing pointer to incomplete type return BN_num_bits(k->dsa->p); ^ sshkey.c: In function 'sshkey_new': sshkey.c:478:11: error: dereferencing pointer to incomplete type (rsa->n = BN_new()) == NULL || ^ [ 112 more like that ] -------------------------------------------------------------------------------- (8) On GoboLinux, I get gcc -std=c99 -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 ../includes.h:168:0, from arc4random.c:27: ../defines.h:391:28: error: conflicting types for 'fd_mask' typedef unsigned long int fd_mask; ^ In file included from /usr/local/include/sys/types.h:219:0, from ../includes.h:25, from arc4random.c:27: ... many more ... -------------------------------------------------------------------------------- (9) On Hipster, OpenIndiana 11, Solaris 10, and Solaris 11, with different compilers, I get similar to this: /opt/solarisstudio12.4/bin/c99 -I/usr/local/include -D_XOPEN_SOURCE=600 -D_XPG6 -I/include -I. -I.. -I. -I./.. -I/include -DHAVE_CONFIG_H -c arc4random.c "../openbsd-compat/openbsd-compat.h", line 205: warning: dubious tag declaration: struct winsize "../buffer.h", line 58: warning: old-style declaration or incorrect type for: u_short "../buffer.h", line 58: syntax error before or at: buffer_get_short "../buffer.h", line 58: warning: old-style declaration or incorrect type for: buffer_get_short "../buffer.h", line 59: syntax error before or at: u_short "../buffer.h", line 59: warning: undefined or missing type for: u_short "../buffer.h", line 82: syntax error before or at: * "../buffer.h", line 82: warning: undefined or missing type for: Buffer c99: acomp failed for arc4random.c -------------------------------------------------------------------------------- (10) On Minix 3.4.0, where /bin/sh is a Bourne-like shell of unknown origin, the build dies with a shell error: if test "cat" = "cat"; then manpage=./`echo moduli.5.out | sed 's/\.[1-9]\.out$/\.0/'`; else manpage=./`echo moduli.5.out | sed 's/\.out$//'`; fi; if test "cat" = "man"; then /usr/bin/sed -e 's|/etc/ssh/ssh_config|/usr/uumath/etc/ssh_config|g' -e 's|/etc/ssh/ssh_known_hosts|/usr/uumath/etc/ssh_known_hosts|g' -e 's|/etc/ssh/sshd_config|/usr/uumath/etc/sshd_config|g' -e 's|/usr/libexec|/usr/uumath/libexec|g' -e 's|/etc/shosts.equiv|/usr/uumath/etc/shosts.equiv|g' -e 's|/etc/ssh/ssh_host_key|/usr/uumath/etc/ssh_host_key|g' -e 's|/etc/ssh/ssh_host_ecdsa_key|/usr/uumath/etc/ssh_host_ecdsa_key|g' -e 's|/etc/ssh/ssh_host_dsa_key|/usr/uumath/etc/ssh_host_dsa_key|g' -e 's|/etc/ssh/ssh_host_rsa_key|/usr/uumath/etc/ssh_host_rsa_key|g' -e 's|/etc/ssh/ssh_host_ed25519_key|/usr/uumath/etc/ssh_host_ed25519_key|g' -e 's|/var/run/sshd.pid|/var/run/sshd.pid|g' -e 's|/etc/moduli|/usr/uumath/etc/moduli|g' -e 's|/etc/ssh/moduli|/usr/uumath/etc/moduli|g' -e 's|/etc/ssh/sshrc|/usr/uumath/etc/sshrc|g' -e 's|/usr/X11R6/bin/xauth|/usr/X11R7/bin/xauth|g' -e 's|/var/empty|/var/empty|g' -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g' ${manpage} | /usr/uumath/bin/tcsh ./fixalgorithms /usr/bin/sed | gawk -f ./mdoc2man.awk > moduli.5.out; else /usr/bin/sed -e 's|/etc/ssh/ssh_config|/usr/uumath/etc/ssh_config|g' -e 's|/etc/ssh/ssh_known_hosts|/usr/uumath/etc/ssh_known_hosts|g' -e 's|/etc/ssh/sshd_config|/usr/uumath/etc/sshd_config|g' -e 's|/usr/libexec|/usr/uumath/libexec|g' -e 's|/etc/shosts.equiv|/usr/uumath/etc/shosts.equiv|g' -e 's|/etc/ssh/ssh_host_key|/usr/uumath/etc/ssh_host_key|g' -e 's|/etc/ssh/ssh_host_ecdsa_key|/usr/uumath/etc/ssh_host_ecdsa_key|g' -e 's|/etc/ssh/ssh_host_dsa_key|/usr/uumath/etc/ssh_host_dsa_key|g' -e 's|/etc/ssh/ssh_host_rsa_key|/usr/uumath/etc/ssh_host_rsa_key|g' -e 's|/etc/ssh/ssh_host_ed25519_key|/usr/uumath/etc/ssh_host_ed25519_key|g' -e 's|/var/run/sshd.pid|/var/run/sshd.pid|g' -e 's|/etc/moduli|/usr/uumath/etc/moduli|g' -e 's|/etc/ssh/moduli|/usr/uumath/etc/moduli|g' -e 's|/etc/ssh/sshrc|/usr/uumath/etc/sshrc|g' -e 's|/usr/X11R6/bin/xauth|/usr/X11R7/bin/xauth|g' -e 's|/var/empty|/var/empty|g' -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g' ${manpage} | /usr/uumath/bin/tcsh ./fixalgorithms /usr/bin/sed > moduli.5.out; fi Badly placed ()'s. *** Error code 1 -------------------------------------------------------------------------------- (11) On Mac OS X 10.5.8 (9L30) Leopard on PowerPC, the compiler warns about possible use-before-initialization and other issues: glob.c:186: warning: implicit declaration of function 'strnlen' pwcache.c:44:1: warning: "MASK" redefined /usr/include/ppc/param.h:123:1: warning: this is the location of the previous definition setproctitle.c:128: warning: 'len' may be used uninitialized in this function sshkey.c:1575: warning: 'eg' may be used uninitialized in this function sshkey.c:3038: warning: 'ivlen' may be used uninitialized in this function sshkey.c:3038: warning: 'keylen' may be used uninitialized in this function packet.c:1052: warning: comparison between signed and unsigned ssh.c:1510: warning: 'daemon' is deprecated (declared at /usr/include/stdlib.h:283) ssh.c:1522: warning: 'daemon' is deprecated (declared at /usr/include/stdlib.h:283) sshconnect.c:309: warning: implicit declaration of function 'bindresvport_sa' ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From john at voipsupport.it Fri Dec 23 23:10:42 2016 From: john at voipsupport.it (John Fawcett) Date: Fri, 23 Dec 2016 13:10:42 +0100 Subject: Bug report - segfault sshd Message-ID: When logging in via ssh with user root and password authentication I get a segfault in sshd. The problem is 100% reproduceable - I cannot login remotely at all. Any help appreciated in trying to get this addressed. This is a centos 7.3 with all the latest updates applied openssh-6.6.1p1-31.el7.x86_64 Here's a backtrace captured by running sshd under gdb. /usr/sbin/sshd -d [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". process 14806 is executing new program: /usr/sbin/sshd Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.5.8-3.el7.x86_64 nss-softokn-freebl-3.16.2.3-14.4.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after fork from child process 14810. Program received signal SIGSEGV, Segmentation fault. __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:212 212 movlpd (%rdi), %xmm1 Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 cracklib-2.9.0-11.el7.x86_64 elfutils-libelf-0.166-2.el7.x86_64 elfutils-libs-0.166-2.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-8.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 libpwquality-1.2.3-4.el7.x86_64 nss-softokn-freebl-3.16.2.3-14.4.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 systemd-libs-219-30.el7_3.6.x86_64 xz-libs-5.2.2-1.el7.x86_64 #0 __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:212 #1 0x0000555555584f2f in sshpam_auth_passwd (authctxt=authctxt at entry=0x55555581fdb0, password=password at entry=0x555555839900 "************") at auth-pam.c:1207 #2 0x000055555556446b in auth_password (authctxt=0x55555581fdb0, password=password at entry=0x555555839900 "************") at auth-passwd.c:149 #3 0x0000555555578daa in mm_answer_authpassword (sock=5, m=0x7fffffffda10) at monitor.c:860 #4 0x000055555557b9b1 in monitor_read (pmonitor=pmonitor at entry=0x55555581efb0, ent=0x55555580a390 , pent=pent at entry=0x7fffffffda78) at monitor.c:586 #5 0x000055555557c7bc in monitor_child_preauth (_authctxt=_authctxt at entry=0x55555581fdb0, pmonitor=0x55555581efb0) at monitor.c:374 #6 0x00005555555615f5 in privsep_preauth (authctxt=0x55555581fdb0) at sshd.c:681 #7 main (ac=, av=) at sshd.c:2094 From jjelen at redhat.com Sat Dec 24 05:04:30 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Fri, 23 Dec 2016 19:04:30 +0100 Subject: Call for testing: OpenSSH 7.4 In-Reply-To: References: Message-ID: <13cd7f13-f2ed-135d-cd2f-760142f5f2cd@redhat.com> On 12/14/2016 01:53 AM, Damien Miller wrote: > * sshd(8): Remove the UseLogin configuration directive and support > for having /bin/login manage login sessions. Hi all, this option should go away also from the example sshd_config in the repository so it will not confuse users. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From john at voipsupport.it Sat Dec 24 06:37:20 2016 From: john at voipsupport.it (John Fawcett) Date: Fri, 23 Dec 2016 20:37:20 +0100 Subject: Bug report - segfault sshd In-Reply-To: References: Message-ID: On 12/23/2016 01:10 PM, John Fawcett wrote: > When logging in via ssh with user root and password authentication I get > a segfault in sshd. The problem is 100% reproduceable - I cannot login > remotely at all. Any help appreciated in trying to get this addressed. > > This is a centos 7.3 with all the latest updates applied > > openssh-6.6.1p1-31.el7.x86_64 > > Here's a backtrace captured by running sshd under gdb. > > /usr/sbin/sshd -d > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > process 14806 is executing new program: /usr/sbin/sshd > Missing separate debuginfos, use: debuginfo-install > keyutils-libs-1.5.8-3.el7.x86_64 > nss-softokn-freebl-3.16.2.3-14.4.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Detaching after fork from child process 14810. > > Program received signal SIGSEGV, Segmentation fault. > __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:212 > 212 movlpd (%rdi), %xmm1 > Missing separate debuginfos, use: debuginfo-install > bzip2-libs-1.0.6-13.el7.x86_64 cracklib-2.9.0-11.el7.x86_64 > elfutils-libelf-0.166-2.el7.x86_64 elfutils-libs-0.166-2.el7.x86_64 > keyutils-libs-1.5.8-3.el7.x86_64 libattr-2.4.46-12.el7.x86_64 > libcap-2.22-8.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 > libpwquality-1.2.3-4.el7.x86_64 > nss-softokn-freebl-3.16.2.3-14.4.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 > systemd-libs-219-30.el7_3.6.x86_64 xz-libs-5.2.2-1.el7.x86_64 > #0 __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:212 > #1 0x0000555555584f2f in sshpam_auth_passwd > (authctxt=authctxt at entry=0x55555581fdb0, > password=password at entry=0x555555839900 "************") at auth-pam.c:1207 > #2 0x000055555556446b in auth_password (authctxt=0x55555581fdb0, > password=password at entry=0x555555839900 "************") at auth-passwd.c:149 > #3 0x0000555555578daa in mm_answer_authpassword (sock=5, > m=0x7fffffffda10) at monitor.c:860 > #4 0x000055555557b9b1 in monitor_read > (pmonitor=pmonitor at entry=0x55555581efb0, ent=0x55555580a390 > , pent=pent at entry=0x7fffffffda78) at monitor.c:586 > #5 0x000055555557c7bc in monitor_child_preauth > (_authctxt=_authctxt at entry=0x55555581fdb0, pmonitor=0x55555581efb0) at > monitor.c:374 > #6 0x00005555555615f5 in privsep_preauth (authctxt=0x55555581fdb0) at > sshd.c:681 > #7 main (ac=, av=) at sshd.c:2094 > I reinstalled openssh-server package and it is now working. I am assuming there was some corruption. John From rcmuir at gmail.com Tue Dec 27 07:33:47 2016 From: rcmuir at gmail.com (rcmuir at gmail.com) Date: Mon, 26 Dec 2016 15:33:47 -0500 Subject: [PATCH] Add VPN tunnel support for Darwin's utun device. Message-ID: <20161226203347.10005-1-rcmuir@gmail.com> From: Robert Muir This tunnel device is available out of box since OS X 10.6. I found a previous discussion [1] but no patches anywhere yet. [1] http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-October/033012.html --- configure.ac | 9 ++++++- openbsd-compat/port-tun.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++ openbsd-compat/port-tun.h | 3 ++- 3 files changed, 70 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index eb9f45dc..74a1e0bd 100644 --- a/configure.ac +++ b/configure.ac @@ -618,7 +618,14 @@ main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16)) AC_DEFINE([BROKEN_GLOB], [1], [OS X glob does not do what we expect]) AC_DEFINE_UNQUOTED([BIND_8_COMPAT], [1], [Define if your resolver libs need this for getrrsetbyname]) - AC_DEFINE([SSH_TUN_FREEBSD], [1], [Open tunnel devices the FreeBSD way]) + AC_CHECK_HEADERS([net/if_utun.h]) + if test "x$ac_cv_header_net_if_utun_h" = "xyes" ; then + AC_DEFINE([SSH_TUN_DARWIN], [1], + [Open tunnel devices the Darwin way]) + else + AC_DEFINE([SSH_TUN_FREEBSD], [1], + [Open tunnel devices the FreeBSD way]) + fi AC_DEFINE([SSH_TUN_COMPAT_AF], [1], [Use tunnel device compatibility to OpenBSD]) AC_DEFINE([SSH_TUN_PREPEND_AF], [1], diff --git a/openbsd-compat/port-tun.c b/openbsd-compat/port-tun.c index a444adf1..7eac9a70 100644 --- a/openbsd-compat/port-tun.c +++ b/openbsd-compat/port-tun.c @@ -43,6 +43,7 @@ * * SSH_TUN_LINUX Use the (newer) Linux tun/tap device * SSH_TUN_FREEBSD Use the FreeBSD tun/tap device + * SSH_TUN_DARWIN Use the Darwin utun device * SSH_TUN_COMPAT_AF Translate the OpenBSD address family * SSH_TUN_PREPEND_AF Prepend/remove the address family */ @@ -194,6 +195,65 @@ sys_tun_open(int tun, int mode) } #endif /* SSH_TUN_FREEBSD */ +#ifdef SSH_TUN_DARWIN +#include +#include +#include + +int +sys_tun_open(int tun, int mode) +{ + struct ctl_info info; + struct sockaddr_ctl addr; + int fd; + + if (tun != SSH_TUNID_ANY && tun > SSH_TUNID_MAX) { + debug("%s: invalid tunnel %u", __func__, tun); + return (-1); + } + + if (mode == SSH_TUNMODE_ETHERNET) { + debug("%s: no layer 2 tunnelling support", __func__); + return (-1); + } + + fd = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL); + if (fd == -1) { + debug("%s: failed to create control socket: %s", + __func__, strerror(errno)); + return (-1); + } + + bzero(&info, sizeof(info)); + strlcpy(info.ctl_name, UTUN_CONTROL_NAME, sizeof(info.ctl_name)); + if (ioctl(fd, CTLIOCGINFO, &info) == -1) { + debug("%s: failed to lookup utun control id: %s", + __func__, strerror(errno)); + goto failed; + } + + bzero(&addr, sizeof(addr)); + addr.sc_id = info.ctl_id; + addr.sc_len = sizeof(addr); + addr.sc_family = AF_SYSTEM; + addr.ss_sysaddr = AF_SYS_CONTROL; + if (tun != SSH_TUNID_ANY) + addr.sc_unit = tun + 1; + + if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) { + debug("%s: failed to connect to utun device: %s", + __func__, strerror(errno)); + goto failed; + } + + return (fd); + + failed: + close(fd); + return (-1); +} +#endif /* SSH_TUN_DARWIN */ + /* * System-specific channel filters */ diff --git a/openbsd-compat/port-tun.h b/openbsd-compat/port-tun.h index c53df01f..e2a51f15 100644 --- a/openbsd-compat/port-tun.h +++ b/openbsd-compat/port-tun.h @@ -19,7 +19,8 @@ struct Channel; -#if defined(SSH_TUN_LINUX) || defined(SSH_TUN_FREEBSD) +#if defined(SSH_TUN_LINUX) || defined(SSH_TUN_FREEBSD) || \ + defined(SSH_TUN_DARWIN) # define CUSTOM_SYS_TUN_OPEN int sys_tun_open(int, int); #endif -- 2.11.0 From rcmuir at gmail.com Tue Dec 27 08:59:52 2016 From: rcmuir at gmail.com (rcmuir at gmail.com) Date: Mon, 26 Dec 2016 16:59:52 -0500 Subject: [PATCH] Add VPN tunnel support for Darwin's utun device. In-Reply-To: <20161226203347.10005-1-rcmuir@gmail.com> References: <20161226203347.10005-1-rcmuir@gmail.com> Message-ID: <20161226215952.62001-1-rcmuir@gmail.com> From: Robert Muir My patch had a mistake in the configure.ac, corrected version here. Cheers, Robert --- configure.ac | 17 ++++++++++---- openbsd-compat/port-tun.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++ openbsd-compat/port-tun.h | 3 ++- 3 files changed, 74 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index eb9f45dc..7f2fd418 100644 --- a/configure.ac +++ b/configure.ac @@ -618,11 +618,18 @@ main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16)) AC_DEFINE([BROKEN_GLOB], [1], [OS X glob does not do what we expect]) AC_DEFINE_UNQUOTED([BIND_8_COMPAT], [1], [Define if your resolver libs need this for getrrsetbyname]) - AC_DEFINE([SSH_TUN_FREEBSD], [1], [Open tunnel devices the FreeBSD way]) - AC_DEFINE([SSH_TUN_COMPAT_AF], [1], - [Use tunnel device compatibility to OpenBSD]) - AC_DEFINE([SSH_TUN_PREPEND_AF], [1], - [Prepend the address family to IP tunnel traffic]) + AC_CHECK_HEADERS([net/if_utun.h]) + if test "x$ac_cv_header_net_if_utun_h" = "xyes" ; then + AC_DEFINE([SSH_TUN_DARWIN], [1], + [Open tunnel devices the Darwin way]) + else + AC_DEFINE([SSH_TUN_FREEBSD], [1], + [Open tunnel devices the FreeBSD way]) + AC_DEFINE([SSH_TUN_PREPEND_AF], [1], + [Prepend the address family to IP tunnel traffic]) + AC_DEFINE([SSH_TUN_COMPAT_AF], [1], + [Use tunnel device compatibility to OpenBSD]) + fi m4_pattern_allow([AU_IPv]) AC_CHECK_DECL([AU_IPv4], [], AC_DEFINE([AU_IPv4], [0], [System only supports IPv4 audit records]) diff --git a/openbsd-compat/port-tun.c b/openbsd-compat/port-tun.c index a444adf1..7eac9a70 100644 --- a/openbsd-compat/port-tun.c +++ b/openbsd-compat/port-tun.c @@ -43,6 +43,7 @@ * * SSH_TUN_LINUX Use the (newer) Linux tun/tap device * SSH_TUN_FREEBSD Use the FreeBSD tun/tap device + * SSH_TUN_DARWIN Use the Darwin utun device * SSH_TUN_COMPAT_AF Translate the OpenBSD address family * SSH_TUN_PREPEND_AF Prepend/remove the address family */ @@ -194,6 +195,65 @@ sys_tun_open(int tun, int mode) } #endif /* SSH_TUN_FREEBSD */ +#ifdef SSH_TUN_DARWIN +#include +#include +#include + +int +sys_tun_open(int tun, int mode) +{ + struct ctl_info info; + struct sockaddr_ctl addr; + int fd; + + if (tun != SSH_TUNID_ANY && tun > SSH_TUNID_MAX) { + debug("%s: invalid tunnel %u", __func__, tun); + return (-1); + } + + if (mode == SSH_TUNMODE_ETHERNET) { + debug("%s: no layer 2 tunnelling support", __func__); + return (-1); + } + + fd = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL); + if (fd == -1) { + debug("%s: failed to create control socket: %s", + __func__, strerror(errno)); + return (-1); + } + + bzero(&info, sizeof(info)); + strlcpy(info.ctl_name, UTUN_CONTROL_NAME, sizeof(info.ctl_name)); + if (ioctl(fd, CTLIOCGINFO, &info) == -1) { + debug("%s: failed to lookup utun control id: %s", + __func__, strerror(errno)); + goto failed; + } + + bzero(&addr, sizeof(addr)); + addr.sc_id = info.ctl_id; + addr.sc_len = sizeof(addr); + addr.sc_family = AF_SYSTEM; + addr.ss_sysaddr = AF_SYS_CONTROL; + if (tun != SSH_TUNID_ANY) + addr.sc_unit = tun + 1; + + if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) { + debug("%s: failed to connect to utun device: %s", + __func__, strerror(errno)); + goto failed; + } + + return (fd); + + failed: + close(fd); + return (-1); +} +#endif /* SSH_TUN_DARWIN */ + /* * System-specific channel filters */ diff --git a/openbsd-compat/port-tun.h b/openbsd-compat/port-tun.h index c53df01f..e2a51f15 100644 --- a/openbsd-compat/port-tun.h +++ b/openbsd-compat/port-tun.h @@ -19,7 +19,8 @@ struct Channel; -#if defined(SSH_TUN_LINUX) || defined(SSH_TUN_FREEBSD) +#if defined(SSH_TUN_LINUX) || defined(SSH_TUN_FREEBSD) || \ + defined(SSH_TUN_DARWIN) # define CUSTOM_SYS_TUN_OPEN int sys_tun_open(int, int); #endif -- 2.11.0 From lists at manon.de Wed Dec 28 13:51:44 2016 From: lists at manon.de (Manon Goo) Date: Wed, 28 Dec 2016 03:51:44 +0100 Subject: certificates keys on pkcs11 devices Message-ID: <731FFBFF46A3EBEFA2CF8976@dynhost-116-17.cgnhome.manon.de> Hi, I have not found any way to use a Certificate with ssh-agent when my Key is stored on a pkcs11 device. I can add my key with ssh-add -s /usr/local/lib/opensc-pkcs11.so but ssh-add -s /usr/local/lib/opensc-pkcs11.so ~/.ssh/mykey-cert.pub does not add the certificate to my agent. As far as I undestand, in ssh-add.c line 580 if (pkcs11provider != NULL) { if (update_card(agent_fd, !deleting, pkcs11provider) == -1) ret = 1; goto done; } does not check for additional (certifcate)-files files on the command line and update_card neither does. Is there any intention to change this? Thanks in alot, Manon From imorgan at nas.nasa.gov Thu Dec 29 09:35:32 2016 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 28 Dec 2016 14:35:32 -0800 Subject: DEFAULT_PKCS11_WHITELIST on 64-bit Linux systems Message-ID: <20161228223532.GA3634@linux124.nas.nasa.gov> Hello, On RHEL 6/amd64, the stock value for DEFAULT_PKCS11_WHITELIST is not very useful. On such systems, /usr/lib64/* would need to be added to the pattern list. Although users can specify the -P option every time they launch ssh-agent, it might be nice to provide a means to specify a default whitelist at build-time. It's tempting to suggest that configure should automatically supply a reasonable value for the whitelist based on the platform, but supporting an option to configure would seem to be the simpler and safer solution. % ./configure --with-default-pkcs11-whitelist="/usr/lib64/*' any thought? -- Iain Morgan From djm at mindrot.org Fri Dec 30 12:40:53 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Dec 2016 12:40:53 +1100 (AEDT) Subject: DEFAULT_PKCS11_WHITELIST on 64-bit Linux systems In-Reply-To: <20161228223532.GA3634@linux124.nas.nasa.gov> References: <20161228223532.GA3634@linux124.nas.nasa.gov> Message-ID: On Wed, 28 Dec 2016, Iain Morgan wrote: > Hello, > > On RHEL 6/amd64, the stock value for DEFAULT_PKCS11_WHITELIST is not > very useful. On such systems, /usr/lib64/* would need to be added to the > pattern list. Although users can specify the -P option every time they > launch ssh-agent, it might be nice to provide a means to specify a > default whitelist at build-time. > > It's tempting to suggest that configure should automatically supply a > reasonable value for the whitelist based on the platform, but supporting > an option to configure would seem to be the simpler and safer solution. > > % ./configure --with-default-pkcs11-whitelist="/usr/lib64/*' Sounds eminently reasonable. Maybe we could make the portable default "/usr/lib*/*,/usr/local/lib*/*" too? -d From cjwatson at debian.org Sat Dec 31 23:55:52 2016 From: cjwatson at debian.org (Colin Watson) Date: Sat, 31 Dec 2016 12:55:52 +0000 Subject: Baffling regress/forwarding.sh failure, new in 7.4p1 Message-ID: <20161231125552.GB17564@riva.ucam.org> I have the OpenSSH regression tests hooked up to run in Debian and Ubuntu's "autopkgtest" system, so that they're automatically run on uploads of OpenSSH itself or any of its dependencies. This is especially good for enforcing interoperability between it and other SSH implementations, but it's also pretty good for throwing up occasional extremely-hard-to-debug failures since the only way I can get more information out of the test nodes is to upload packages to Debian unstable. In this case I have a new failure in 7.4p1 that didn't occur in 7.3p1. I'm seeing it on Debian amd64 and Ubuntu s390x, so from context I think it's specific to the case where we're using autopkgtest's LXC virtualisation mode. I can run the tests locally, but so far haven't managed to reproduce this failure that way. I arranged to run all tests under TEST_SHELL='sh -x' and to dump failed-{regress,ssh,sshd}.log on failures. Can anyone make anything out of this? run test forwarding.sh ... + _POSIX2_VERSION=199209 + export _POSIX2_VERSION + uname -s + [ ! -z ] + PORT=4242 + [ -x /usr/ucb/whoami ] + whoami + whoami + USER=openssh-tests + OBJ=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress + [ x/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress = x ] + [ ! -d /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress ] + SCRIPT=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/forwarding.sh + [ x/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/forwarding.sh = x ] + [ ! -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/forwarding.sh ] + sh -x -n /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/forwarding.sh + true + unset SSH_AUTH_SOCK + dirname /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/forwarding.sh + SRC=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress + SSH=ssh + SSHD=sshd + SSHAGENT=ssh-agent + SSHADD=ssh-add + SSHKEYGEN=ssh-keygen + SSHKEYSCAN=ssh-keyscan + SFTP=sftp + SFTPSERVER=/usr/libexec/openssh/sftp-server + SCP=scp + PLINK=plink + PUTTYGEN=puttygen + CONCH=conch + [ x != x ] + [ x != x ] + [ x != x ] + [ x != x ] + [ x != x ] + [ x != x ] + [ x != x ] + [ x/usr/lib/openssh/sftp-server != x ] + SFTPSERVER=/usr/lib/openssh/sftp-server + [ x != x ] + [ xplink != x ] + which plink + PLINK=/usr/bin/plink + [ xputtygen != x ] + which puttygen + PUTTYGEN=/usr/bin/puttygen + [ xconch != x ] + which conch + CONCH=/usr/bin/conch + SSH_PROTOCOLS=2 + [ x != x ] + which sshd + SSHD=/usr/sbin/sshd + which ssh-agent + SSHAGENT=/usr/bin/ssh-agent + SSH_BIN=ssh + SSHD_BIN=/usr/sbin/sshd + SSHAGENT_BIN=/usr/bin/ssh-agent + SSHADD_BIN=ssh-add + SSHKEYGEN_BIN=ssh-keygen + SSHKEYSCAN_BIN=ssh-keyscan + SFTP_BIN=sftp + SFTPSERVER_BIN=/usr/lib/openssh/sftp-server + SCP_BIN=scp + [ x != x ] + [ x = x ] + TEST_SSH_LOGFILE=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh.log + [ x = x ] + TEST_SSHD_LOGFILE=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd.log + [ x = x ] + TEST_REGRESS_LOGFILE=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/regress.log + + + + SSHLOGWRAP=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh + echo #!/bin/sh + echo exec ssh -E/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh.log "$@" + chmod a+rx /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh + REAL_SSH=ssh + SSH=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh + DATANAME=data + DATA=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/data + cat /usr/bin/ssh-agent + chmod u+w /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/data + COPY=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + rm -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + export SSH SSHD SSHAGENT SSHADD SSHKEYGEN SSHKEYSCAN SFTP SFTPSERVER SCP + RESULT=0 + PIDFILE=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile + trap fatal 3 2 + ssh_version 1 + echo 2+ grep 1 + PROTO=2 + cat + [ ! -z ] + [ ! -z ] + cp /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd_config /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd_proxy + echo StrictModes no + cat + [ ! -z ] + rm -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/known_hosts /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/authorized_keys_openssh-tests + ssh_version 1 + echo 2 + grep 1 + SSH_KEYTYPES=rsa ed25519 + trace generate keys + start_debug_log generate keys + echo trace: generate keys + echo trace: generate keys + echo trace: generate keys + [ X = Xyes ] + [ ! -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa ] + [ ssh-keygen -nt /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa ] + printf localhost-with-alias,127.0.0.1,::1 + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa.pub + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa.pub + echo IdentityFile /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa + sudo cp /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/host.rsa + echo HostKey /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/host.rsa + echo HostKey /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/rsa + [ ! -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519 ] + [ ssh-keygen -nt /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519 ] + printf localhost-with-alias,127.0.0.1,::1 + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519.pub + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519.pub + echo IdentityFile /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519 + sudo cp /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519 /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/host.ed25519 + echo HostKey /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/host.ed25519 + echo HostKey /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ed25519 + chmod 644 /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/authorized_keys_openssh-tests + REGRESS_INTEROP_CONCH=no + test -x /usr/bin/conch + REGRESS_INTEROP_CONCH=yes + REGRESS_INTEROP_PUTTY=no + test -x /usr/bin/puttygen -a -x /usr/bin/plink + REGRESS_INTEROP_PUTTY=yes + REGRESS_INTEROP_PUTTY=no + test no = yes + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config + echo proxycommand sudo sh /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd-log-wrapper.sh /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd.log /usr/sbin/sshd -i -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd_proxy + /usr/sbin/sshd -t -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd_proxy + . /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/forwarding.sh + tid=local and remote forwarding + DATA=/bin/ls + start_sshd + sudo /usr/sbin/sshd -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd_config -t + sudo /usr/sbin/sshd -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd_config -E/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd.log + trace wait for sshd + start_debug_log wait for sshd + echo trace: wait for sshd + echo trace: wait for sshd + echo trace: wait for sshd + [ X = Xyes ] + i=0 + [ ! -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile -a 0 -lt 10 ] + test -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile + base=33 + last=4242 + fwd= + CTL=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ctl-sock + rm -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ctl-sock + a=3300 + expr 3300 + 50 + b=3350 + c=4242 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 + last=3300 + a=3301 + expr 3301 + 50 + b=3351 + c=3300 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 + last=3301 + a=3302 + expr 3302 + 50 + b=3352 + c=3301 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 + last=3302 + a=3310 + expr 3310 + 50 + b=3360 + c=3302 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 + last=3310 + a=3311 + expr 3311 + 50 + b=3361 + c=3310 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 -L3311:127.0.0.1:3361 -R3361:127.0.0.1:3310 + last=3311 + a=3312 + expr 3312 + 50 + b=3362 + c=3311 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 -L3311:127.0.0.1:3361 -R3361:127.0.0.1:3310 -L3312:127.0.0.1:3362 -R3362:127.0.0.1:3311 + last=3312 + a=3320 + expr 3320 + 50 + b=3370 + c=3312 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 -L3311:127.0.0.1:3361 -R3361:127.0.0.1:3310 -L3312:127.0.0.1:3362 -R3362:127.0.0.1:3311 -L3320:127.0.0.1:3370 -R3370:127.0.0.1:3312 + last=3320 + a=3321 + expr 3321 + 50 + b=3371 + c=3320 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 -L3311:127.0.0.1:3361 -R3361:127.0.0.1:3310 -L3312:127.0.0.1:3362 -R3362:127.0.0.1:3311 -L3320:127.0.0.1:3370 -R3370:127.0.0.1:3312 -L3321:127.0.0.1:3371 -R3371:127.0.0.1:3320 + last=3321 + a=3322 + expr 3322 + 50 + b=3372 + c=3321 + fwd= -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 -L3311:127.0.0.1:3361 -R3361:127.0.0.1:3310 -L3312:127.0.0.1:3362 -R3362:127.0.0.1:3311 -L3320:127.0.0.1:3370 -R3370:127.0.0.1:3312 -L3321:127.0.0.1:3371 -R3371:127.0.0.1:3320 -L3322:127.0.0.1:3372 -R3372:127.0.0.1:3321 + last=3322 + expr 3 - 2 + q=1 + ssh_version 1 + echo 2 + grep 1 + q=2 + trace start forwarding, fork to background + start_debug_log start forwarding, fork to background + echo trace: start forwarding, fork to background + echo trace: start forwarding, fork to background + echo trace: start forwarding, fork to background + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -f -L3300:127.0.0.1:3350 -R3350:127.0.0.1:4242 -L3301:127.0.0.1:3351 -R3351:127.0.0.1:3300 -L3302:127.0.0.1:3352 -R3352:127.0.0.1:3301 -L3310:127.0.0.1:3360 -R3360:127.0.0.1:3302 -L3311:127.0.0.1:3361 -R3361:127.0.0.1:3310 -L3312:127.0.0.1:3362 -R3362:127.0.0.1:3311 -L3320:127.0.0.1:3370 -R3370:127.0.0.1:3312 -L3321:127.0.0.1:3371 -R3371:127.0.0.1:3320 -L3322:127.0.0.1:3372 -R3372:127.0.0.1:3321 somehost sleep 10 + trace transfer over forwarded channels and check result + start_debug_log transfer over forwarded channels and check result + echo trace: transfer over forwarded channels and check result + echo trace: transfer over forwarded channels and check result + echo trace: transfer over forwarded channels and check result + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -p3322 -o ConnectionAttempts=4 somehost cat /bin/ls + test -s /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + cmp /bin/ls /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + sleep 10 + trace exit on -L forward failure, proto 2 + start_debug_log exit on -L forward failure, proto 2 + echo trace: exit on -L forward failure, proto 2 + echo trace: exit on -L forward failure, proto 2 + echo trace: exit on -L forward failure, proto 2 + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -L 3301:127.0.0.1:4242 -L 3302:127.0.0.1:4242 -L 3303:127.0.0.1:4242 -L 3304:127.0.0.1:4242 -oExitOnForwardFailure=yes somehost true + [ 0 != 0 ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -q -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -L 3301:127.0.0.1:4242 -L 3302:127.0.0.1:4242 -L 3303:127.0.0.1:4242 -L 3301:localhost:4242 -L 3304:127.0.0.1:4242 -oExitOnForwardFailure=yes somehost true + r=255 + [ 255 != 255 ] + trace exit on -R forward failure, proto 2 + start_debug_log exit on -R forward failure, proto 2 + echo trace: exit on -R forward failure, proto 2 + echo trace: exit on -R forward failure, proto 2 + echo trace: exit on -R forward failure, proto 2 + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -R 3301:127.0.0.1:4242 -R 3302:127.0.0.1:4242 -R 3303:127.0.0.1:4242 -R 3304:127.0.0.1:4242 -oExitOnForwardFailure=yes somehost true + [ 0 != 0 ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -q -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -R 3301:127.0.0.1:4242 -R 3302:127.0.0.1:4242 -R 3303:127.0.0.1:4242 -R 3301:localhost:4242 -R 3304:127.0.0.1:4242 -oExitOnForwardFailure=yes somehost true + r=255 + [ 255 != 255 ] + trace simple clear forwarding proto 2 + start_debug_log simple clear forwarding proto 2 + echo trace: simple clear forwarding proto 2 + echo trace: simple clear forwarding proto 2 + echo trace: simple clear forwarding proto 2 + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -oClearAllForwardings=yes somehost true + trace clear local forward proto 2 + start_debug_log clear local forward proto 2 + echo trace: clear local forward proto 2 + echo trace: clear local forward proto 2 + echo trace: clear local forward proto 2 + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -f -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -L 3301:127.0.0.1:4242 -oClearAllForwardings=yes somehost sleep 10 + [ 0 != 0 ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -p 3301 true + sleep 10 + trace clear remote forward proto 2 + start_debug_log clear remote forward proto 2 + echo trace: clear remote forward proto 2 + echo trace: clear remote forward proto 2 + echo trace: clear remote forward proto 2 + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -f -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -R 3301:127.0.0.1:4242 -oClearAllForwardings=yes somehost sleep 10 + [ 0 != 0 ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -p 3301 true + sleep 10 + trace stdio forwarding proto 2 + start_debug_log stdio forwarding proto 2 + echo trace: stdio forwarding proto 2 + echo trace: stdio forwarding proto 2 + echo trace: stdio forwarding proto 2 + [ X = Xyes ] + cmd=/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -o ProxyCommand /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -q -W localhost:4242 somehost somehost true + [ 0 != 0 ] + echo LocalForward 3301 127.0.0.1:4242 + echo RemoteForward 3302 127.0.0.1:3301 + trace config file: start forwarding, fork to background + start_debug_log config file: start forwarding, fork to background + echo trace: config file: start forwarding, fork to background + echo trace: config file: start forwarding, fork to background + echo trace: config file: start forwarding, fork to background + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -S /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ctl-sock -M -2 -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -f somehost sleep 10 + trace config file: transfer over forwarded channels and check result + start_debug_log config file: transfer over forwarded channels and check result + echo trace: config file: transfer over forwarded channels and check result + echo trace: config file: transfer over forwarded channels and check result + echo trace: config file: transfer over forwarded channels and check result + [ X = Xyes ] + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -p3302 -o ConnectionAttempts=4 somehost cat /bin/ls + test -s /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + fail failed copy of /bin/ls + save_debug_log FAIL: failed copy of /bin/ls + echo FAIL: failed copy of /bin/ls + echo FAIL: failed copy of /bin/ls + echo FAIL: failed copy of /bin/ls + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/regress.log + echo + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh.log + echo + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd.log + echo + RESULT=1 + echo failed copy of /bin/ls + cmp /bin/ls /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy failed copy of /bin/ls cmp: EOF on /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + fail corrupted copy of /bin/ls + save_debug_log FAIL: corrupted copy of /bin/ls + echo FAIL: corrupted copy of /bin/ls + echo FAIL: corrupted copy of /bin/ls + echo FAIL: corrupted copy of /bin/ls + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/regress.log + echo + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh.log + echo + cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/sshd.log + echo + RESULT=1 + echo corrupted copy of /bin/ls + corrupted copy of /bin/ls /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -S /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ctl-sock -O exit somehost + trace transfer over chained unix domain socket forwards and check result + start_debug_log transfer over chained unix domain socket forwards and check result + echo trace: transfer over chained unix domain socket forwards and check result + echo trace: transfer over chained unix domain socket forwards and check result + echo trace: transfer over chained unix domain socket forwards and check result + [ X = Xyes ] + rm -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-[123].fwd + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -f -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -R3301:[/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-1.fwd] somehost sleep 10 + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -f -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -L[/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-1.fwd]:[/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-2.fwd] somehost sleep 10 + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -f -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -R[/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-2.fwd]:[/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-3.fwd] somehost sleep 10 + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -f -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -L[/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/unix-3.fwd]:127.0.0.1:4242 somehost sleep 10 + /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh-log-wrapper.sh -F /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/ssh_config -p3301 -o ConnectionAttempts=4 somehost cat /bin/ls + test -s /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + cmp /bin/ls /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/copy + sleep 10 + cleanup + [ x != x ] + stop_sshd + [ -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile ] + sudo cat /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile + pid=32570 + [ X32570 = X ] + [ 32570 -lt 2 ] + sudo kill 32570 + trace wait for sshd to exit + start_debug_log wait for sshd to exit + echo trace: wait for sshd to exit + echo trace: wait for sshd to exit + echo trace: wait for sshd to exit + [ X = Xyes ] + i=0 + [ -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile -a 0 -lt 5 ] + test -f /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/pidfile + [ 1 -eq 0 ] + echo failed local and remote forwarding + exit 1 failed local and remote forwarding Makefile:199: recipe for target 't-exec' failed make: Leaving directory '/tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress' make: *** [t-exec] Error 1 ==> /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/failed-regress.log <== trace: config file: transfer over forwarded channels and check result FAIL: failed copy of /bin/ls trace: config file: transfer over forwarded channels and check result FAIL: failed copy of /bin/ls FAIL: corrupted copy of /bin/ls ==> /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/failed-ssh.log <== trace: config file: transfer over forwarded channels and check result debug2: resolving "127.0.0.1" port 3302 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused debug1: Trying again... debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused debug1: Trying again... debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused debug1: Trying again... debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused ssh: connect to host 127.0.0.1 port 3302: Connection refused FAIL: failed copy of /bin/ls trace: config file: transfer over forwarded channels and check result debug2: resolving "127.0.0.1" port 3302 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused debug1: Trying again... debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused debug1: Trying again... debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused debug1: Trying again... debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3302. debug1: connect to address 127.0.0.1 port 3302: Connection refused ssh: connect to host 127.0.0.1 port 3302: Connection refused FAIL: failed copy of /bin/ls FAIL: corrupted copy of /bin/ls ==> /tmp/autopkgtest-virt-lxc.shared.hhquaatj/downtmp/autopkgtest_tmp/user/tree/regress/failed-sshd.log <== trace: config file: transfer over forwarded channels and check result dWCUHL3hrO9Sb+pyo0ZTZvaU debug3: notify_hostkeys: sent 2 hostkeys debug3: send packet: type 80 debug1: Entering interactive session for SSH2. debug2: fd 7 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug1: server_init_dispatch debug3: receive packet: type 80 debug1: server_input_global_request: rtype tcpip-forward want_reply 1 debug1: server_input_global_request: tcpip-forward listen localhost port 3302 debug3: channel_setup_fwd_listener_tcpip: type 11 wildcard 0 addr NULL debug1: Local forwarding listening on 127.0.0.1 port 3302. debug2: fd 9 setting O_NONBLOCK debug3: fd 9 is O_NONBLOCK debug1: channel 0: new [port listener] debug3: send packet: type 81 packet_write_wait: Connection from 127.0.0.1 port 60879: Broken pipe debug1: do_cleanup debug3: mm_request_receive entering debug1: do_cleanup debug1: audit_event: unhandled event 12 FAIL: failed copy of /bin/ls trace: config file: transfer over forwarded channels and check result dWCUHL3hrO9Sb+pyo0ZTZvaU debug3: notify_hostkeys: sent 2 hostkeys debug3: send packet: type 80 debug1: Entering interactive session for SSH2. debug2: fd 7 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug1: server_init_dispatch debug3: receive packet: type 80 debug1: server_input_global_request: rtype tcpip-forward want_reply 1 debug1: server_input_global_request: tcpip-forward listen localhost port 3302 debug3: channel_setup_fwd_listener_tcpip: type 11 wildcard 0 addr NULL debug1: Local forwarding listening on 127.0.0.1 port 3302. debug2: fd 9 setting O_NONBLOCK debug3: fd 9 is O_NONBLOCK debug1: channel 0: new [port listener] debug3: send packet: type 81 packet_write_wait: Connection from 127.0.0.1 port 60879: Broken pipe debug1: do_cleanup debug3: mm_request_receive entering debug1: do_cleanup debug1: audit_event: unhandled event 12 FAIL: failed copy of /bin/ls FAIL: corrupted copy of /bin/ls Full output here: https://ci.debian.net/data/packages/unstable/amd64/o/openssh/20161231_044927.autopkgtest.log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/s390x/o/openssh/20161231_120523_ebc8a@/log.gz Thanks, -- Colin Watson [cjwatson at debian.org]