From stefbon at gmail.com Fri Jun 2 02:26:17 2017 From: stefbon at gmail.com (Stef Bon) Date: Thu, 1 Jun 2017 18:26:17 +0200 Subject: Get remote address when using direct-streamlocal@openssh.com. Message-ID: I've a server where clients can connect to using direct-streamlocal at openssh.com. I want that the server "knows" the address of the client. I've tried using the peercredentials of the process connecting my server (which is a sshd process) and check the environment. I thought that in the environment the var SSH_CLIENT would be set, but that did not work. This sshd process has an almost empty environment file. Is there another good way to find it? Thanks in advance, Stef Bon From stefbon at gmail.com Fri Jun 2 16:15:50 2017 From: stefbon at gmail.com (Stef Bon) Date: Fri, 2 Jun 2017 08:15:50 +0200 Subject: Get remote address when using direct-streamlocal@openssh.com. In-Reply-To: References: Message-ID: Hi, I can create something what works: the client has the ability to create a channel using the same ssh session with the server, and can execute commands. When the client has a connection with the server using the direct-streamlocal mechanism, it can also create a file on the server by running something like: set > /tmp/sshd_set_%PPID% the parent pid is the same pid my serverprocess reads when reading the peer socket credentials. My serverprocess waits for the existence of this file, and when detected, it reads the environmentvariables like SSH_CLIENT. This will work, but is very constructed. might there be another easier way? Thanks in advance. Stef From debian.axhn at manchmal.in-ulm.de Mon Jun 5 21:30:00 2017 From: debian.axhn at manchmal.in-ulm.de (Christoph Biedl) Date: Mon, 5 Jun 2017 13:30:00 +0200 Subject: [patch] Fix incoming compression statistics Message-ID: <1496662044@msgid.manchmal.in-ulm.de> Hello, somewhere between 6.7 and 7.4, the compression statistics shown when running the client with -C -v got messed up. For the incoming compression, the numbers for outgoing are used, reversed. This got reported in https://bugs.debian.org/797964 but appearently was never forwarded upstream. Trivial patch below, kudos to Russell Coker. Christoph --- openssh-7.2p2.orig/packet.c +++ openssh-7.2p2/packet.c @@ -525,7 +525,7 @@ ssh_packet_close(struct ssh *ssh) deflateEnd(stream); } if (state->compression_in_started) { - z_streamp stream = &state->compression_out_stream; + z_streamp stream = &state->compression_in_stream; debug("compress incoming: " "raw data %llu, compressed %llu, factor %.2f", (unsigned long long)stream->total_out, From adrian.wilkins at gmail.com Mon Jun 5 23:38:32 2017 From: adrian.wilkins at gmail.com (Adrian Wilkins) Date: Mon, 5 Jun 2017 14:38:32 +0100 Subject: Slow connects due to out-of-context DNS lookup In-Reply-To: References: <43bcebdd-ddc4-e89c-0ed7-4c0d8e86f5ed@gmail.com> Message-ID: <6cd612e1-4e31-2546-64d0-f1370d63e84f@gmail.com> On 01/03/17 21:33, Damien Miller wrote: > Please send verbose output, i.e. "ssh -vvv ..." > Sorry for the large delay... Attached logs. Have anonymised some things. No notable differences that I can spot. The *-host.log file is with an entry pointing to localhost in /etc/hosts The other is without this entry. The "with" session connects instantly. The "without" session takes much longer. The pauses occur during the segment of log below the line. Setting "GSSAPIAuthentication no" for this configuration (not the configuration for the proxy SSH server) causes it to take the same amount of time as when you insert a definition of the remote host DNS name in /etc/hosts ---- debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available ---- -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-graylog.log Type: text/x-log Size: 15857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-graylog-host.log Type: text/x-log Size: 15858 bytes Desc: not available URL: From dtucker at zip.com.au Tue Jun 6 19:20:14 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 6 Jun 2017 19:20:14 +1000 Subject: [patch] Fix incoming compression statistics In-Reply-To: <1496662044@msgid.manchmal.in-ulm.de> References: <1496662044@msgid.manchmal.in-ulm.de> Message-ID: On Mon, Jun 5, 2017 at 9:30 PM, Christoph Biedl wrote: > somewhere between 6.7 and 7.4, the compression statistics shown when > running the client with -C -v got messed up. For the record it was in OpenBSD's rev 1.201 which corresponds to v6.8. > For the incoming > compression, the numbers for outgoing are used, reversed. Patch 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 stefbon at gmail.com Thu Jun 8 23:39:23 2017 From: stefbon at gmail.com (Stef Bon) Date: Thu, 8 Jun 2017 15:39:23 +0200 Subject: Confusing new format. Message-ID: Hi, I'm writing my own ssh library for my fuse fs. It's purpose is to provide sftp access, but also (X) terminalsessions and tunneling of other services (like nfs). I'm also working on an new sftp server, clients can connect using the new streamlocal open channel method. The reason I choose to write my own library is I want a very tight taylormade integration in my fuse fs. Now my ssh library supports the pubkey methods ssh-dss and ssh-rsa. I want to add support for ed25519. When I look at the way clients have stored the keys in files I found openssh uses a new method. So far so good. But now I got stuck. I read in PROTOCOL.key in "1. Overall format" there are a N publickeys stored, and N privatekeys, encrypted. Because the same number is used I can assume that the format describes that there are the same number of privatekeys as publickeys. Now when I look at a ed25519 private hostkey, I see the following: - AUTH_MAGIC (found, ok) - string ciphername (found, value none, ok) - string kdfname (found, value none, ok) - string kdfoptions (found, empty, ok) - integer number of keys (found, value 3, ok?) - string publickey (found, length 32, ok) - string publickey (found, length 32, ok, and the exactly the same as the first) - string encrypted (found, length 64) above string is build as described in "2. Unencrypted list of N private keys": - uint32 int (not found, not ok) - uint32 int (not found, not ok) - string privatekey (found, length 64, ok) - comment (found, length 10, ok) - padding (found, ok) There are some issues: a. the number of keys reported is 3, but it should be 2 or 1, not 3, since the PROTOCOL document uses the same N for public and private keys. And there are 2 public keys included, not 3. So this is confusing. Is the number 3 correct? If so the documentation is wrong. b. the numbers to check the encryption are not present. This is not documented. Can someone clarify? Thanks in advance, Stef Bon From stefbon at gmail.com Fri Jun 9 00:49:58 2017 From: stefbon at gmail.com (Stef Bon) Date: Thu, 8 Jun 2017 16:49:58 +0200 Subject: Confusing new format. In-Reply-To: References: Message-ID: 2017-06-08 15:39 GMT+02:00 Stef Bon : > Hi, > > - integer number of keys (found, value 3, ok?) > - string publickey (found, length 32, ok) > - string publickey (found, length 32, ok, and the exactly the same as the first) > - string encrypted (found, length 64) > > above string is build as described in "2. Unencrypted list of N private keys": > > - uint32 int (not found, not ok) > - uint32 int (not found, not ok) > - string privatekey (found, length 64, ok) I sorry I've made a mistake. The encryptes part starts earlier: it should be: - AUTH_MAGIC (found, ok) - string ciphername (found, value none, ok) - string kdfname (found, value none, ok) - string kdfoptions (found, empty, ok) - integer number of keys (found, value 1, ok) - integer value 00 00 00 33 ( I cannot explain that..) - string name method (found, length 11, ok) - string publickey (found, length 32, ok) - string length 144 - uint32 int (found, ok) - uint32 int (found, ok) - string name method (found, length 11, ok) - string privatekey (found, length 64, ok) - string comment (found, ok) - padding (ok) So the only field not clarified is 00 00 00 33, but when looking at the values this is the length of the string of the name and the key together. So everything solved. Stef From jjelen at redhat.com Tue Jun 13 23:04:51 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 13 Jun 2017 15:04:51 +0200 Subject: PKCS#11 URIs in OpenSSH In-Reply-To: References: Message-ID: <7ed1d87c-876f-5ab7-fea7-2023b70f73d3@redhat.com> On 04/24/2017 02:26 PM, Jakub Jelen wrote: > Hello all, > as PKCS#11 URI became standard (RFC 7512), it would be good to be able > to specify the keys using this notation in openssh. > > So far I implemented the minimal subset of this standard allowing to > specify the URI for the ssh tool, in ssh_config and to work with > ssh-agent. It does not bring any new dependency, provides unit and > regress tests (while fixing agent-pkcs11 regress test). > > The code is on github and ready for comments/reviews (some details will > need to be adjusted): > > https://github.com/openssh/openssh-portable/compare/master...Jakuje:jjelen-pkcs11 > > > I will fill a bugzilla later. I would be grateful for your ideas, > comments or reviews for this feature. > > Other useful parts of RFC, that could be implemented would be a way to > provide a PIN or a PIN source for the token, other ways of providing > module-path (module-name). > > Regards, Hello all, I fixed one issue and added a configure option to pick up default p11-kit-proxy path from pkg-config instead of hardcoded value. https://github.com/openssh/openssh-portable/compare/master...Jakuje:jjelen-pkcs11 Did anyone had a time to review this change? Are you interested in this feature? Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From krahmer at suse.com Wed Jun 14 23:50:36 2017 From: krahmer at suse.com (Sebastian Krahmer) Date: Wed, 14 Jun 2017 15:50:36 +0200 Subject: OpenSSL 1.1.0 support and RSA_set0_key() double frees? Message-ID: <20170614135036.GC13993@suse.de> Hi Our openssh maintainer pointed me to these patches: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html aiming to solve the openssl 1.1. API-change problems. In particular https://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch which seems to be used by fedora, contains code like this: + (r = sshbuf_get_u32(ids, &bits)) != 0 || + (r = sshbuf_get_bignum1(ids, e)) != 0 || + (r = sshbuf_get_bignum1(ids, n)) != 0 || + (RSA_set0_key(key->rsa, n, e, NULL) == 0) || + (r = sshbuf_get_cstring(ids, &comment, NULL)) != 0) { + BN_free(n); + BN_free(e); goto out; ... out: sshkey_free(key); Note, that the manpage says about RSA_set0_key(): "Calling this function transfers the memory management of the values to the RSA object, and therefore the values that have been passed in should not be freed by the caller after this function has been called." So, unless theres some tricky ref-counting inside BN_free() and RSA_free(), that gets called by sshkey_free(), this is a double-free condition. Since RSA_set0_key() may succeed and sshbuf_get_cstring() may fail inside the if. There are various places like this, so the get0/set0 pattern that is used has to be reviewed. I am not sure whether the manpage also forbids calling BN_free() in case of RSA_set0_key() errors. Please take me in Cc, I am not subscribed. Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer at suse.com - SuSE Security Team From djm at mindrot.org Thu Jun 15 10:56:14 2017 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Jun 2017 10:56:14 +1000 (AEST) Subject: OpenSSL 1.1.0 support and RSA_set0_key() double frees? In-Reply-To: <20170614135036.GC13993@suse.de> References: <20170614135036.GC13993@suse.de> Message-ID: On Wed, 14 Jun 2017, Sebastian Krahmer wrote: > Hi > > Our openssh maintainer pointed me to these patches: > > http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html > http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html > > aiming to solve the openssl 1.1. API-change problems. > > In particular > > https://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch > > which seems to be used by fedora, contains code like this: > > > + (r = sshbuf_get_u32(ids, &bits)) != 0 || > + (r = sshbuf_get_bignum1(ids, e)) != 0 || > + (r = sshbuf_get_bignum1(ids, n)) != 0 || > + (RSA_set0_key(key->rsa, n, e, NULL) == 0) || > + (r = sshbuf_get_cstring(ids, &comment, NULL)) != 0) { > + BN_free(n); > + BN_free(e); > goto out; > ... > out: > sshkey_free(key); > > Note, that the manpage says about RSA_set0_key(): > > "Calling this function > transfers the memory management of the values to the RSA object, and > therefore the values that have been passed in should not be freed by > the caller after this function has been called." > > So, unless theres some tricky ref-counting inside BN_free() and > RSA_free(), that gets called by sshkey_free(), this is a double-free > condition. Since RSA_set0_key() may succeed and sshbuf_get_cstring() > may fail inside the if. > > There are various places like this, so the get0/set0 pattern that is > used has to be reviewed. > I am not sure whether the manpage also forbids calling BN_free() > in case of RSA_set0_key() errors. That does look like a double-free, and those are exploitable under some circumstances. The long term solution will be to rework these bits to use the new OpenSSL API, but I'm loathe to do this for reasons I explained in the second thread you linked to. -d From jjelen at redhat.com Thu Jun 15 21:45:41 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Thu, 15 Jun 2017 13:45:41 +0200 Subject: OpenSSL 1.1.0 support and RSA_set0_key() double frees? In-Reply-To: <20170614135036.GC13993@suse.de> References: <20170614135036.GC13993@suse.de> Message-ID: <49833ae7-2b34-513e-5f4a-362d261d3f88@redhat.com> On 06/14/2017 03:50 PM, Sebastian Krahmer wrote: > Hi > > Our openssh maintainer pointed me to these patches: > > http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html > http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html > > aiming to solve the openssl 1.1. API-change problems. > > In particular > > https://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch > > which seems to be used by fedora, contains code like this: > > > + (r = sshbuf_get_u32(ids, &bits)) != 0 || > + (r = sshbuf_get_bignum1(ids, e)) != 0 || > + (r = sshbuf_get_bignum1(ids, n)) != 0 || > + (RSA_set0_key(key->rsa, n, e, NULL) == 0) || > + (r = sshbuf_get_cstring(ids, &comment, NULL)) != 0) { > + BN_free(n); > + BN_free(e); > goto out; > ... > out: > sshkey_free(key); > > Note, that the manpage says about RSA_set0_key(): > > "Calling this function > transfers the memory management of the values to the RSA object, and > therefore the values that have been passed in should not be freed by > the caller after this function has been called." > > So, unless theres some tricky ref-counting inside BN_free() and > RSA_free(), that gets called by sshkey_free(), this is a double-free > condition. Since RSA_set0_key() may succeed and sshbuf_get_cstring() > may fail inside the if. > > There are various places like this, so the get0/set0 pattern that is > used has to be reviewed. > I am not sure whether the manpage also forbids calling BN_free() > in case of RSA_set0_key() errors. > > Please take me in Cc, I am not subscribed. > > Sebastian > Hello Sebastian, thank you for a message. You are right that this could cause some problems. Reading through the code, most of the occurrences are in the SSH1 code which is already gone from upstream. I tried to fix in Fedora repository. [1] Let me know if it is as you would expected or you found some other issues. If so, patches are welcomed. [1] https://src.fedoraproject.org/cgit/rpms/openssh.git/commit/?id=f07a0866 Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From dueno at redhat.com Sat Jun 17 02:17:41 2017 From: dueno at redhat.com (Daiki Ueno) Date: Fri, 16 Jun 2017 18:17:41 +0200 Subject: [PATCH] allow relative path in streamlocal forwarding Message-ID: <20170616161741.12435-1-dueno@redhat.com> When forwarding a Unix-domain socket, the remote socket path must be absolute (otherwise the forwarding fails later). However, guessing absolute path on the remote end is sometimes not straightforward, because the file system location may vary for many reasons, including the system installation, the choices of NFS mount points, or the remote user ID. To allow ssh clients to request remote socket forwarding without knowledge of the remote system, this patch enables the use of relative path in remote socket forwarding. If a relative path is requested as remote_socket, it is expanded from StreamLocalBindRootDirectory, a new option added to sshd_config. This feature would be particularly useful if the remote system is capable of user runtime directory, as managed by pam_systemd: https://www.freedesktop.org/software/systemd/man/pam_systemd.html The applications locating sockets under the runtime directory could transparently access the forwarded sockets, with the following setting: StreamLocalBindRootDirectory /run/user/%i --- channels.c | 104 +++++++++++++++++++++++++++++++++++++++++++++---- channels.h | 2 +- misc.h | 1 + readconf.c | 16 ++++++++ regress/Makefile | 1 + regress/streamlocal.sh | 59 ++++++++++++++++++++++++++++ servconf.c | 21 ++++++++++ serverloop.c | 3 +- ssh.1 | 28 +++++++++++++ sshd.c | 25 ++++++++++++ sshd_config.5 | 11 +++++- 11 files changed, 260 insertions(+), 11 deletions(-) create mode 100644 regress/streamlocal.sh diff --git a/channels.c b/channels.c index 028d5db..97561e0 100644 --- a/channels.c +++ b/channels.c @@ -2996,6 +2996,59 @@ channel_setup_fwd_listener_tcpip(int type, struct Forward *fwd, return success; } +/* Expands a relative socket path to the absolute path, from the given + * root directory. */ +static char * +expand_relative_socket_path(const char *pathname, const char *root_directory) +{ + char *ret, *cp; + struct stat st; + + if (*pathname == '/') + return xstrdup(pathname); + + if (xasprintf(&ret, "%s/%s", root_directory, pathname) >= PATH_MAX) { + error("Socket path too long"); + free(ret); + return NULL; + } + + cp = ret + strlen(root_directory) + 1; + while (*cp != '\0') { + char *cp2 = strchr(cp, '/'); + if (cp2 != NULL) + *cp2 = '\0'; + if (cp2 == cp || strcmp(cp, ".") == 0 || strcmp(cp, "..") == 0) { + error("Invalid socket path"); + free(ret); + return NULL; + } + if (stat(ret, &st) == -1) { + if (cp2 != NULL && errno != ENOENT) { + error("Parent directory is not accessible"); + free(ret); + return NULL; + } + } else { + if (cp2 != NULL && !S_ISDIR(st.st_mode)) { + error("Parent is not a directory"); + free(ret); + return NULL; + } + if (cp2 == NULL && S_ISLNK(st.st_mode)) { + error("Symbolic link is not allowed"); + free(ret); + return NULL; + } + } + if (cp2 == NULL) + break; + *cp2 = '/'; + cp = cp2 + 1; + } + return ret; +} + static int channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd, struct ForwardOptions *fwd_opts) @@ -3005,6 +3058,7 @@ channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd, Channel *c; int port, sock; mode_t omask; + char *listen_path; switch (type) { case SSH_CHANNEL_UNIX_LISTENER: @@ -3042,22 +3096,39 @@ channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd, error("No forward path name."); return 0; } - if (strlen(fwd->listen_path) > sizeof(sunaddr.sun_path)) { - error("Local listening path too long: %s", fwd->listen_path); + + if (fwd->listen_path[0] != '/') { + if (fwd_opts->streamlocal_bind_root_directory == NULL) { + error("Relative path is not enabled."); + return 0; + } + listen_path = expand_relative_socket_path(fwd->listen_path, + fwd_opts->streamlocal_bind_root_directory); + if (listen_path == NULL) + return 0; + } else + listen_path = xstrdup(fwd->listen_path); + + if (strlen(listen_path) > sizeof(sunaddr.sun_path)) { + error("Local listening path too long: %s", listen_path); + free(listen_path); return 0; } - debug3("%s: type %d path %s", __func__, type, fwd->listen_path); + debug3("%s: type %d path %s", __func__, type, listen_path); /* Start a Unix domain listener. */ omask = umask(fwd_opts->streamlocal_bind_mask); - sock = unix_listener(fwd->listen_path, SSH_LISTEN_BACKLOG, + sock = unix_listener(listen_path, SSH_LISTEN_BACKLOG, fwd_opts->streamlocal_bind_unlink); umask(omask); - if (sock < 0) + if (sock < 0) { + free(listen_path); return 0; + } - debug("Local forwarding listening on path %s.", fwd->listen_path); + debug("Local forwarding listening on path %s.", listen_path); + free(listen_path); /* Allocate a channel number for the socket. */ c = channel_new("unix listener", type, sock, sock, -1, @@ -3825,9 +3896,12 @@ channel_connect_to_port(const char *host, u_short port, char *ctype, /* Check if connecting to that path is permitted and connect. */ Channel * -channel_connect_to_path(const char *path, char *ctype, char *rname) +channel_connect_to_path(const char *path, char *ctype, char *rname, + struct ForwardOptions *fwd_opts) { int i, permit, permit_adm = 1; + char *connect_path; + Channel *c; permit = all_opens_permitted; if (!permit) { @@ -3852,7 +3926,21 @@ channel_connect_to_path(const char *path, char *ctype, char *rname) "but the request was denied.", path); return NULL; } - return connect_to(path, PORT_STREAMLOCAL, ctype, rname); + + if (path[0] != '/') { + if (fwd_opts->streamlocal_bind_root_directory == NULL) { + logit("Relative path is not enabled"); + return NULL; + } + connect_path = expand_relative_socket_path(path, + fwd_opts->streamlocal_bind_root_directory); + if (connect_path == NULL) + return NULL; + } else + connect_path = xstrdup(path); + c = connect_to(connect_path, PORT_STREAMLOCAL, ctype, rname); + free(connect_path); + return c; } void diff --git a/channels.h b/channels.h index 36e5363..13b6707 100644 --- a/channels.h +++ b/channels.h @@ -274,7 +274,7 @@ void channel_clear_adm_permitted_opens(void); void channel_print_adm_permitted_opens(void); Channel *channel_connect_to_port(const char *, u_short, char *, char *, int *, const char **); -Channel *channel_connect_to_path(const char *, char *, char *); +Channel *channel_connect_to_path(const char *, char *, char *, struct ForwardOptions *); Channel *channel_connect_stdio_fwd(const char*, u_short, int, int); Channel *channel_connect_by_listen_address(const char *, u_short, char *, char *); diff --git a/misc.h b/misc.h index c242f90..99341f6 100644 --- a/misc.h +++ b/misc.h @@ -38,6 +38,7 @@ struct ForwardOptions { int gateway_ports; /* Allow remote connects to forwarded ports. */ mode_t streamlocal_bind_mask; /* umask for streamlocal binds */ int streamlocal_bind_unlink; /* unlink socket before bind */ + char *streamlocal_bind_root_directory; }; /* misc.c */ diff --git a/readconf.c b/readconf.c index b11c628..13ab320 100644 --- a/readconf.c +++ b/readconf.c @@ -2234,6 +2234,22 @@ parse_forward(struct Forward *fwd, const char *fwdspec, int dynamicfwd, int remo if (fwd->connect_host != NULL && strlen(fwd->connect_host) >= NI_MAXHOST) goto fail_free; + /* The path starting with "./" means that it will be resolved + * on the server side */ + if (!dynamicfwd) { + if (!remotefwd && fwd->connect_path != NULL && + strncmp(fwd->connect_path, "./", 2) == 0) { + char *path = xstrdup(fwd->connect_path + 2); + free(fwd->connect_path); + fwd->connect_path = path; + } + if (remotefwd && fwd->listen_path != NULL && + strncmp(fwd->listen_path, "./", 2) == 0) { + char *path = xstrdup(fwd->listen_path + 2); + free(fwd->listen_path); + fwd->listen_path = path; + } + } /* XXX - if connecting to a remote socket, max sun len may not match this host */ if (fwd->connect_path != NULL && strlen(fwd->connect_path) >= PATH_MAX_SUN) diff --git a/regress/Makefile b/regress/Makefile index f968c41..e6e4f24 100644 --- a/regress/Makefile +++ b/regress/Makefile @@ -52,6 +52,7 @@ LTESTS= connect \ reconfigure \ dynamic-forward \ forwarding \ + streamlocal \ multiplex \ reexec \ brokenkeys \ diff --git a/regress/streamlocal.sh b/regress/streamlocal.sh new file mode 100644 index 0000000..2baa70c --- /dev/null +++ b/regress/streamlocal.sh @@ -0,0 +1,59 @@ +# $OpenBSD: forwarding.sh,v 1.20 2017/04/30 23:34:55 djm Exp $ +# Placed in the Public Domain. + +tid="streamlocal forwarding" + +USER=`id -u` +NC=$OBJ/netcat +REMOTE_DIR=$OBJ/remote-$USER + +start_sshd + +trace "remote forwarding, relative socket path disabled on server" +rm -f $OBJ/localsock +$NC -U -l $OBJ/localsock > /dev/null & +netcat_pid=$! +${SSH} -F $OBJ/ssh_config -p$PORT -o ExitOnForwardFailure=yes -R ./remotesock:$OBJ/localsock somehost true +r=$? +kill $netcat_pid 2>&1 >/dev/null +if [ $r -eq 0 ]; then + fail "should fail if relative socket path is disabled" +fi + +stop_sshd + +start_sshd -o StreamLocalBindRootDirectory=$OBJ/remote-%i + +trace "remote forwarding, relative socket path enabled on server, but has wrong permission" +rm -fr $REMOTE_DIR +mkdir $REMOTE_DIR +chmod 0777 $REMOTE_DIR +rm -f $OBJ/localsock +$NC -U -l $OBJ/localsock > /dev/null & +netcat_pid=$! +${SSH} -F $OBJ/ssh_config -p$PORT -o ExitOnForwardFailure=yes -R ./remotesock:$OBJ/localsock somehost true +r=$? +kill $netcat_pid 2>/dev/null +if [ $r -eq 0 ]; then + fail "should fail if the socket root directory has wrong permission" +fi + +trace "remote forwarding, relative socket path enabled on server, and has right permission" +rm -fr $REMOTE_DIR +mkdir $REMOTE_DIR +chmod 0700 $REMOTE_DIR +rm -f $OBJ/localsock +$NC -U -l $OBJ/localsock > /dev/null & +netcat_pid=$! +${SSH} -F $OBJ/ssh_config -p$PORT -o ExitOnForwardFailure=yes -R ./remotesock:$OBJ/localsock somehost true +r=$? +kill $netcat_pid 2>/dev/null +if [ $r -ne 0 ]; then + fail "should succeed if the socket root directory has right permission" +fi + +stop_sshd + +rm -f $OBJ/localsock +rm -f $OBJ/remotesock +rm -fr $REMOTE_DIR diff --git a/servconf.c b/servconf.c index a112798..ff23418 100644 --- a/servconf.c +++ b/servconf.c @@ -136,6 +136,7 @@ initialize_server_options(ServerOptions *options) options->fwd_opts.gateway_ports = -1; options->fwd_opts.streamlocal_bind_mask = (mode_t)-1; options->fwd_opts.streamlocal_bind_unlink = -1; + options->fwd_opts.streamlocal_bind_root_directory = NULL; options->num_subsystems = 0; options->max_startups_begin = -1; options->max_startups_rate = -1; @@ -355,6 +356,7 @@ fill_default_server_options(ServerOptions *options) CLEAR_ON_NONE(options->authorized_principals_file); CLEAR_ON_NONE(options->adm_forced_command); CLEAR_ON_NONE(options->chroot_directory); + CLEAR_ON_NONE(options->fwd_opts.streamlocal_bind_root_directory); for (i = 0; i < options->num_host_key_files; i++) CLEAR_ON_NONE(options->host_key_files[i]); for (i = 0; i < options->num_host_cert_files; i++) @@ -417,6 +419,7 @@ typedef enum { sAuthorizedKeysCommand, sAuthorizedKeysCommandUser, sAuthenticationMethods, sHostKeyAgent, sPermitUserRC, sStreamLocalBindMask, sStreamLocalBindUnlink, + sStreamLocalBindRootDirectory, sAllowStreamLocalForwarding, sFingerprintHash, sDisableForwarding, sDeprecated, sIgnore, sUnsupported } ServerOpCodes; @@ -558,6 +561,7 @@ static struct { { "authenticationmethods", sAuthenticationMethods, SSHCFG_ALL }, { "streamlocalbindmask", sStreamLocalBindMask, SSHCFG_ALL }, { "streamlocalbindunlink", sStreamLocalBindUnlink, SSHCFG_ALL }, + { "streamlocalbindrootdirectory", sStreamLocalBindRootDirectory, SSHCFG_ALL }, { "allowstreamlocalforwarding", sAllowStreamLocalForwarding, SSHCFG_ALL }, { "fingerprinthash", sFingerprintHash, SSHCFG_GLOBAL }, { "disableforwarding", sDisableForwarding, SSHCFG_ALL }, @@ -1823,6 +1827,17 @@ process_server_config_line(ServerOptions *options, char *line, intptr = &options->fwd_opts.streamlocal_bind_unlink; goto parse_flag; + case sStreamLocalBindRootDirectory: + charptr = &options->fwd_opts.streamlocal_bind_root_directory; + + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing file name.", + filename, linenum); + if (*activep && *charptr == NULL) + *charptr = xstrdup(arg); + break; + case sFingerprintHash: arg = strdelim(&cp); if (!arg || *arg == '\0') @@ -2039,6 +2054,11 @@ copy_set_server_options(ServerOptions *dst, ServerOptions *src, int preauth) free(dst->chroot_directory); dst->chroot_directory = NULL; } + M_CP_STROPT(fwd_opts.streamlocal_bind_root_directory); + if (option_clear_or_none(dst->fwd_opts.streamlocal_bind_root_directory)) { + free(dst->fwd_opts.streamlocal_bind_root_directory); + dst->fwd_opts.streamlocal_bind_root_directory = NULL; + } } #undef M_CP_INTOPT @@ -2300,6 +2320,7 @@ dump_config(ServerOptions *o) o->hostkeyalgorithms : KEX_DEFAULT_PK_ALG); dump_cfg_string(sPubkeyAcceptedKeyTypes, o->pubkey_key_types ? o->pubkey_key_types : KEX_DEFAULT_PK_ALG); + dump_cfg_string(sStreamLocalBindRootDirectory, o->fwd_opts.streamlocal_bind_root_directory); /* string arguments requiring a lookup */ dump_cfg_string(sLogLevel, log_level_name(o->log_level)); diff --git a/serverloop.c b/serverloop.c index b5eb344..f295a3f 100644 --- a/serverloop.c +++ b/serverloop.c @@ -488,7 +488,8 @@ server_request_direct_streamlocal(void) !no_port_forwarding_flag && !options.disable_forwarding && (pw->pw_uid == 0 || use_privsep)) { c = channel_connect_to_path(target, - "direct-streamlocal at openssh.com", "direct-streamlocal"); + "direct-streamlocal at openssh.com", "direct-streamlocal", + &options.fwd_opts); } else { logit("refused streamlocal port forward: " "originator %s port %d, target %s", diff --git a/ssh.1 b/ssh.1 index 3aacec4..e26e1b5 100644 --- a/ssh.1 +++ b/ssh.1 @@ -352,6 +352,20 @@ or the Unix socket .Ar remote_socket , from the remote machine. .Pp +.Ar remote_socket +can be either an absolute path or a relative path. If it is a +relative path, it is resolved on the remote host, based on the +.Cm StreamLocalBindRootDirectory +setting. +In order to avoid confusion between service name and socket path, +.Sq ./ +can be prefixed to explicitly indicate that the path be relative. +Note that even if relative paths are allowed, path name traversal is +restricted to directories excluding +.Sq .. +and +.Sq \&. . +.Pp Port forwardings can also be specified in the configuration file. Only the superuser can forward privileged ports. IPv6 addresses can be specified by enclosing the address in square brackets. @@ -608,6 +622,20 @@ or .Ar local_socket , from the local machine. .Pp +.Ar remote_socket +can be either an absolute path or a relative path. If it is a +relative path, it is resolved on the remote host, based on the +.Cm StreamLocalBindRootDirectory +setting. +In order to avoid confusion between service name and socket path, +.Sq ./ +can be prefixed to explicitly indicate that the path be relative. +Note that even if relative paths are allowed, path name traversal is +restricted to directories excluding +.Sq .. +and +.Sq \&. . +.Pp Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only when logging in as root on the remote machine. diff --git a/sshd.c b/sshd.c index 06cb81f..ba0207f 100644 --- a/sshd.c +++ b/sshd.c @@ -2077,6 +2077,31 @@ main(int ac, char **av) /* the monitor process [priv] will not return */ } + /* Process per-user options */ + if (options.fwd_opts.streamlocal_bind_root_directory != NULL) { + char uidstr[32], *cp; + struct stat st; + + snprintf(uidstr, sizeof(uidstr), "%d", authctxt->pw->pw_uid); + + cp = tilde_expand_filename( + options.fwd_opts.streamlocal_bind_root_directory, + authctxt->pw->pw_uid); + free(options.fwd_opts.streamlocal_bind_root_directory); + options.fwd_opts.streamlocal_bind_root_directory = + percent_expand(cp, + "u", authctxt->pw->pw_name, + "i", uidstr, + (char *)NULL); + free(cp); + if (stat(options.fwd_opts.streamlocal_bind_root_directory, &st) == -1) + fatal("%s is not accessible", + options.fwd_opts.streamlocal_bind_root_directory); + if (st.st_uid != authctxt->pw->pw_uid || (st.st_mode & 077) != 0) + fatal("Bad ownership or modes for directory %s", + options.fwd_opts.streamlocal_bind_root_directory); + } + packet_set_timeout(options.client_alive_interval, options.client_alive_count_max); diff --git a/sshd_config.5 b/sshd_config.5 index 7b4cb1d..0f1cf3f 100644 --- a/sshd_config.5 +++ b/sshd_config.5 @@ -1368,6 +1368,11 @@ or .Cm no . The default is .Cm no . +.It Cm StreamLocalBindRootDirectory +Specifies the root directory where a Unix-domain socket file for +remote port forwarding is created, if the requested path is relative. +.Pp +The directory must be readable and writable only by the owner. .It Cm StrictModes Specifies whether .Xr sshd 8 @@ -1613,7 +1618,8 @@ The fingerprint of the key or certificate. .It %h The home directory of the user. .It %i -The key ID in the certificate. +The key ID in the certificate if used in AuthorizedPrincipalsCommand, +or the user ID otherwise. .It %K The base64-encoded CA key. .It %k @@ -1642,6 +1648,9 @@ accepts the tokens %%, %h, and %u. .Pp .Cm ChrootDirectory accepts the tokens %%, %h, and %u. +.Pp +.Cm StreamLocalBindRootDirectory +accepts the tokens %%, %i, and %u. .Sh FILES .Bl -tag -width Ds .It Pa /etc/ssh/sshd_config -- 2.9.4 From jjelen at redhat.com Tue Jun 20 02:26:09 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 19 Jun 2017 18:26:09 +0200 Subject: OpenSSL 1.1.0 support and RSA_set0_key() double frees? In-Reply-To: References: Message-ID: <16789ff8-d4f2-f3ad-766f-f5b77d5c87ba@redhat.com> On 06/19/2017 06:16 PM, Yekkirala, Venkatesh Sri wrote: > Hi Jakub, > > The patch for this introduces an unconditional goto at line 3344: > > http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch#n3344 > > as shown in the below snippet: > > /* calculate p-1 and q-1 */ > - if ((r = rsa_generate_additional_parameters(prv->rsa)) != 0) > + if ((r = rsa_generate_additional_parameters(prv->rsa, iqmp)) != 0) > + BN_free(iqmp); > goto out; > > /* enable blinding */ > > FYI, > > venkat > Thank you for a review. Should be fixed now. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From vyekkira at illinois.edu Tue Jun 20 02:16:33 2017 From: vyekkira at illinois.edu (Yekkirala, Venkatesh Sri) Date: Mon, 19 Jun 2017 16:16:33 +0000 Subject: OpenSSL 1.1.0 support and RSA_set0_key() double frees? Message-ID: Hi Jakub, The patch for this introduces an unconditional goto at line 3344: http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch#n3344 as shown in the below snippet: /* calculate p-1 and q-1 */ - if ((r = rsa_generate_additional_parameters(prv->rsa)) != 0) + if ((r = rsa_generate_additional_parameters(prv->rsa, iqmp)) != 0) + BN_free(iqmp); goto out; /* enable blinding */ FYI, venkat From stefbon at gmail.com Wed Jun 21 19:21:05 2017 From: stefbon at gmail.com (Stef Bon) Date: Wed, 21 Jun 2017 11:21:05 +0200 Subject: [PATCH] allow relative path in streamlocal forwarding In-Reply-To: <20170616161741.12435-1-dueno@redhat.com> References: <20170616161741.12435-1-dueno@redhat.com> Message-ID: 2017-06-16 18:17 GMT+02:00 Daiki Ueno : > When forwarding a Unix-domain socket, the remote socket path must be > absolute (otherwise the forwarding fails later). However, guessing > absolute path on the remote end is sometimes not straightforward, > because the file system location may vary for many reasons, including > the system installation, the choices of NFS mount points, or the > remote user ID. You can put a lot into openssh, but isn't this a bit too much? ssh is a transport protocol, and nothing more. Make openssh expanding paths is not the task of the openssh daemons in my opinion. Better would be if you have a session to a remote host, run a script on the reomote host via SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_REQUEST to run a command to get the result. The reply should be the path to the socket. Close the I'm working on a sftp client and sftp server for linux, using the same streamlocal method to connect to a socket on the server. This works very nice. Stef Bon the Netherlands From stefbon at gmail.com Wed Jun 21 20:08:31 2017 From: stefbon at gmail.com (Stef Bon) Date: Wed, 21 Jun 2017 12:08:31 +0200 Subject: Get remote address when using direct-streamlocal@openssh.com. In-Reply-To: References: Message-ID: 2017-06-02 8:15 GMT+02:00 Stef Bon : > > This will work, but is very constructed. might there be another easier way? Hi, I'm thinking about using pam for this purpose. My fileserver watches a file with fanotify, getting the pid of the process which wants to open and write to a file, for example /run/ssh-remote-access The sshd process uses a pammodule (pam_bfileserver for example in the session phase of pam) which writes information like: %PID%:%PAM_RHOST%:%PAM_RUSER% to this file. While it is busy doing so, other processes are blocked to write to it. When this data is written, bfileserver reads these values, compares with the pid fanotify reported, and if they match, bfileserver "knows" the remote address. bfileserver clears the file, and allows access to it by other processes. The pammodule should proceed if file not found. Stef From Vincent.Riera at imgtec.com Wed Jun 21 20:17:36 2017 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Wed, 21 Jun 2017 11:17:36 +0100 Subject: [PATCH 1/2] configure.ac: detect MIPS ABI Message-ID: <20170621101737.36594-1-Vincent.Riera@imgtec.com> Signed-off-by: Vicente Olivert Riera --- configure.ac | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/configure.ac b/configure.ac index 18079acb..f990cfe0 100644 --- a/configure.ac +++ b/configure.ac @@ -746,6 +746,27 @@ main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16)) fi AC_CHECK_HEADERS([linux/seccomp.h linux/filter.h linux/audit.h], [], [], [#include ]) + # Obtain MIPS ABI + case "$host" in + mips*) + AC_COMPILE_IFELSE([ +#if _MIPS_SIM != _ABIO32 +#error +#endif + ],[mips_abi="o32"],[AC_COMPILE_IFELSE([ +#if _MIPS_SIM != _ABIN32 +#error +#endif + ],[mips_abi="n32"],[AC_COMPILE_IFELSE([ +#if _MIPS_SIM != _ABI64 +#error +#endif + ],[mips_abi="n64"],[AC_MSG_ERROR([unknown MIPS ABI]) + ]) + ]) + ]) + ;; + esac AC_MSG_CHECKING([for seccomp architecture]) seccomp_audit_arch= case "$host" in -- 2.13.0 From Vincent.Riera at imgtec.com Wed Jun 21 20:17:37 2017 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Wed, 21 Jun 2017 11:17:37 +0100 Subject: [PATCH 2/2] configure.ac: properly set seccomp_audit_arch for MIPS64 In-Reply-To: <20170621101737.36594-1-Vincent.Riera@imgtec.com> References: <20170621101737.36594-1-Vincent.Riera@imgtec.com> Message-ID: <20170621101737.36594-2-Vincent.Riera@imgtec.com> Currently seccomp_audit_arch is set to AUDIT_ARCH_MIPS64 or AUDIT_ARCH_MIPSEL64 (depending on the endinness) when openssh is built for MIPS64. However, that's only valid for n64 ABI. The right macros for n32 ABI defined in seccomp.h are AUDIT_ARCH_MIPS64N32 and AUDIT_ARCH_MIPSEL64N32, for big and little endian respectively. Because of that an sshd built for MIPS64 n32 rejects connection attempts and the output of strace reveals that the problem is related to seccomp audit: [pid 194] prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len=57, filter=0x555d5da0}) = 0 [pid 194] write(7, "\0\0\0]\0\0\0\5\0\0\0Ulist_hostkey_types: "..., 97) = ? [pid 193] <... poll resumed> ) = 2 ([{fd=5, revents=POLLIN|POLLHUP}, {fd=6, revents=POLLHUP}]) [pid 194] +++ killed by SIGSYS +++ This patch fixes that problem by setting the right value to seccomp_audit_arch taking into account the MIPS64 ABI. Signed-off-by: Vicente Olivert Riera --- configure.ac | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f990cfe0..5d640f67 100644 --- a/configure.ac +++ b/configure.ac @@ -801,10 +801,24 @@ main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16)) seccomp_audit_arch=AUDIT_ARCH_MIPSEL ;; mips64-*) - seccomp_audit_arch=AUDIT_ARCH_MIPS64 + case "$mips_abi" in + "n32") + seccomp_audit_arch=AUDIT_ARCH_MIPS64N32 + ;; + "n64") + seccomp_audit_arch=AUDIT_ARCH_MIPS64 + ;; + esac ;; mips64el-*) - seccomp_audit_arch=AUDIT_ARCH_MIPSEL64 + case "$mips_abi" in + "n32") + seccomp_audit_arch=AUDIT_ARCH_MIPSEL64N32 + ;; + "n64") + seccomp_audit_arch=AUDIT_ARCH_MIPSEL64 + ;; + esac ;; esac if test "x$seccomp_audit_arch" != "x" ; then -- 2.13.0 From dueno at redhat.com Wed Jun 21 23:38:53 2017 From: dueno at redhat.com (Daiki Ueno) Date: Wed, 21 Jun 2017 15:38:53 +0200 Subject: [PATCH] allow relative path in streamlocal forwarding In-Reply-To: (Stef Bon's message of "Wed, 21 Jun 2017 11:21:05 +0200") References: <20170616161741.12435-1-dueno@redhat.com> Message-ID: Stef Bon writes: > Make openssh expanding paths is not the task of the openssh daemons in > my opinion. > Better would be if you have a session to a remote host, run a script > on the reomote host > via SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_REQUEST to run a command > to get the result. Yes, it would make sense to let client expand a remote path using remote command execution. That would be probably safer and more flexible. On the other hand, as my initial goal was to forward sockets under $XDG_RUNTIME_DIR seamlessly, I was hoping it would be possible only with the standard ssh command, without complicated command line options nor invoking the command multiple times. Regards, -- Daiki Ueno From haris.phnx at gmail.com Thu Jun 22 17:00:52 2017 From: haris.phnx at gmail.com (haris iqbal) Date: Thu, 22 Jun 2017 12:30:52 +0530 Subject: Adding support for SHA-1 and higher algorithms to the NetBSD openssh V5.0 Message-ID: Hi, I wanted to know whether there is a way of adding support to SHA2 and higher ciphers to the NetBsd version of the openssh, without updating to the latest release. My NetBsd version of openssh is V5.0 -- With regards, Md Haris Iqbal, Contact: +91 8861996962 From dtucker at zip.com.au Thu Jun 22 21:41:11 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 22 Jun 2017 21:41:11 +1000 Subject: Adding support for SHA-1 and higher algorithms to the NetBSD openssh V5.0 In-Reply-To: References: Message-ID: On Thu, Jun 22, 2017 at 5:00 PM, haris iqbal wrote: > I wanted to know whether there is a way of adding support to SHA2 and > higher ciphers to the NetBsd version of the openssh, without updating > to the latest release. > > My NetBsd version of openssh is V5.0 Probably not without a fair amount of effort. Why would you want to do that? -- 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 martin at oneiros.de Thu Jun 22 22:00:14 2017 From: martin at oneiros.de (=?UTF-8?Q?Martin_Schr=C3=B6der?=) Date: Thu, 22 Jun 2017 14:00:14 +0200 Subject: Adding support for SHA-1 and higher algorithms to the NetBSD openssh V5.0 In-Reply-To: References: Message-ID: 2017-06-22 9:00 GMT+02:00 haris iqbal : > My NetBsd version of openssh is V5.0 Congrats! Your Openssh is 9 years old! https://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-585/version_id-58395/Openbsd-Openssh-5.0.html Upgrade. Best Martin From logout at free.fr Fri Jun 23 08:26:47 2017 From: logout at free.fr (Emmanuel Deloget) Date: Fri, 23 Jun 2017 00:26:47 +0200 Subject: OpenSSL 1.1 support status : what next? Message-ID: Hello everybody, ? ? I saw that another discussion about OpenSSL 1.1 support started on this list, and I'd like to know what is the current status about this. >From what I understand, at least ?one patch set already exists: ? ? a github PR [1] from , Kurt Roeckx announced on the list in september 2016 [2] ? and which also exist as a fedora patch [3]? (I haven't checked the details, and maybe the PR and the fedora patch are a bit different). ?The problems that were signaled during the september/november 2016 discussion and the recent one are: * it breaks LibreSSL builds * the changes are only relevant to openssh-portable * it involves maintaining a shim which might be buggy * openssl 1.0.2 is LTS and support is longer than for openssl 1.1.0 * a few major distributions (including some older RHEL versions) are stuck with even older releases ?* changes in openssl 1.1 are not a sufficient motive to do the job anyway? * this is quite a large change (the fedora patch is more than 3000 lines long) Forces that would drive the changes are: * fedora already has it. * latest debian unstable are to be based upon OpenSSL 1.1. * ?eventually 1.0.2 will fade out so being ready to support openssl 1.1 (and later versions) is likely to pay out at some time ?* a late change is going to be even larger than the current fedora patch (hello, technical debt). ? ?* ?new features in future openssl release ?I probably missed a few thing here and there. Now, I recently completed a similar change for OpenVPN [4] - as the currently proposed patch, it involves a shim, although this one is made of static inlines in a header file. It allowed the OpenVPN team to add an openssl 1.1 build target on travis and subsequent changes will be tested against this build target (so new openssl 1.0.x artefact cannot be introduced again in the code) as well as against already existing targets (meaning that introducing the use of another openssl 1.1 function into the code will force a change in the shim). So it basically takes care of everything. Report has been made that it does not break the LibreSSL build. For further ease of management, the shim itself is broken in multiple parts. The configure script checks for the presence of each OpenSSL 1.1 needed function, and one #define is generated for each function. The code does not really care if the function comes from 1.1.0 or 1.0.2. ? I was in the process of doing something similar for openssh-portable when I found out about Kurt's patch. His work is more advanced than mine, so I'm wondering if I should continue (I can always rework his patch to adapt it to the process I outline above ; furthermore I think there might be other issues than the double free [5] in the code, but I have to double or triple check my intuition here, as I kind of always get wrong when I state something like this). My opinion is: * the openssl team has no real incentive to propose a shim ; moreover such an "official" shim is not guaranteed to be used by downstream. * an independant openssl shim project is likely to fail -- it stills require a large amount of work for downstream projects as they still need to adapt their code to the new openssl API. * so downstream projects are kind of forced to implement their own shim anyway ?. I fully understand that it's not an ideal solution.? ? ?I believe it's possible to build a shim with the following features: * compatible with openssl 1.0 to 1.1 and current versions of libressl (e.g. the one in OpenVPN has been tested with openssl 0.9.8 ; when I started development RHEL 4 was not yet eol'ed) * easy to change when an openssl version is deprecated * small enough to avoid security bugs in the shim itself The latest is especially important, and my intuition is that most of the shim (if not all) is made of functions whose goal is to either get or set openssl structure members. This code is quite straigtforward and should not pose any threat. Compatibility with libressl is granted as long as the shim implement missing (openssl 1.0.2+) functions using the openssl 1.0.1 API. This should be guaranteed until the eol of openssl 1.0.2. A problem may arise if we need to implement openssl 1.2+ API using the openssl 1.1 API (yet we still have some time before we'll face this situation). Ease of change is always relative, but the goal is to limit the number of changes when one must add or remove a function from the shim. ?Did I miss something? ?Is the community interested in having support for openssl 1.1? What should an ideal openssl 1.1 support look like? Do you have any question? Comment? How many question mark can I add in the paragraph? ?Best regards, -- Emmanuel Deloget? [1] https://github.com/openssh/openssh-portable/pull/48 [2] http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html ?[3] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch ? [4] https://github.com/OpenVPN/openvpn [5] http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-June/036083.html From schwarze at usta.de Fri Jun 23 09:26:31 2017 From: schwarze at usta.de (Ingo Schwarze) Date: Fri, 23 Jun 2017 01:26:31 +0200 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: Message-ID: <20170622232631.GD77030@athene.usta.de> Hi Emmanuel, Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200: > * the openssl team has no real incentive to propose a shim ; If major application projects refuse to support their new release, thus putting pressure on operating system distributions to not completely switch to 1.1 either, that is not an incentive? > Did I miss something? Maybe you are striving for the wrong goal. It is not a goal to clobber something together and encourage OpenSSL to repeat such recklessness in the future, and leave users out in the rain once again. It is not a goal either to create a shim that is not officially audited and thoroughly tested by the original authors who know their original code best, to create a shim that creates additional dangers for security. We are talking about security software here, so this is not the place at all to lightly cobble something together, in particular not in ways involving many lines of additional code. If a few important projects keep up resistance and refuse support for 1.1 until OpenSSL rolls up their sleeves and fixes the mess they have created, maybe they will eventually realize that they started a job here, wandered off half-way, and failed to ever properly finish it. So, such resistance has a chance to improve the situation for everybody. And i can't think of many projects that are in as widespread use as OpenSSH, and hence can be more valuable with respect to such resistance. Just my personal 2 cents, yours, Ingo From cjwatson at debian.org Fri Jun 23 19:05:56 2017 From: cjwatson at debian.org (Colin Watson) Date: Fri, 23 Jun 2017 10:05:56 +0100 Subject: [PATCH 0/3] Allow syscalls for openssl engines In-Reply-To: <3407217a-6c43-e8b2-b80e-5d14a2462a01@linux.vnet.ibm.com> References: <1494350835-24813-1-git-send-email-ebarretto@linux.vnet.ibm.com> <3407217a-6c43-e8b2-b80e-5d14a2462a01@linux.vnet.ibm.com> Message-ID: <20170623090556.mwlolwsipvci7jpr@riva.ucam.org> On Thu, May 18, 2017 at 10:17:50AM -0300, Eduardo Barretto wrote: > On 09-05-2017 14:27, Eduardo Barretto wrote: > > This patchset allow syscalls (flock, ipc, getuid, geteuid and ioctl), so > > openssl engines, e.g. OpenSSL-ibmca and OpenSSL-ibmpkcs11, can work and > > communicate with the crypto cards during ssh login. > > Hi there, > > Is there any doubts or information that I can help with? I'm also interested to know if anyone has had a chance to review this patch set, since Ubuntu is currently carrying a part of it in order to support hardware acceleration on s390x. It may be a good idea for you to turn this into a bug report on bugzilla.mindrot.org so that it doesn't get lost. -- Colin Watson [cjwatson at debian.org] From logout at free.fr Fri Jun 23 21:53:24 2017 From: logout at free.fr (Emmanuel Deloget) Date: Fri, 23 Jun 2017 13:53:24 +0200 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: <20170622232631.GD77030@athene.usta.de> References: <20170622232631.GD77030@athene.usta.de> Message-ID: Hello Ingo, On Fri, Jun 23, 2017 at 1:26 AM, Ingo Schwarze wrote: > > Hi Emmanuel, > > Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200: > > > * the openssl team has no real incentive to propose a shim ; > > If major application projects refuse to support their new release, > thus putting pressure on operating system distributions to not > completely switch to 1.1 either, that is not an incentive? Yes and no. The fact is that openssl is widely used by tons of projects. Even if a major project quits (and frankly, these days openssh is built around libressl, not openssl, so one car argue that openssh already leaved the boat) there is little incentive for the openssl to not continue in the same direction as other projects will follow anyway -- mostly because openssl is openssl, not because openssl is great (*). Why would the openssl team do that ? * it's time consuming, and their time is better spent on enhancing the security and features of the openssl libs * such a project is doomed. It would make the various downstream project move to the openssl 1.1 API, at which point the remaining distros will dump older versions, meaning that the shim will have a life duration of one, maybe two years. * yet during these two years, it might become a stable (as introduces by R.C. Martin : a stable software is one who as many clients and a limited set of dependencies), meaning that every little change in it might have tremendous effects on downstream projects. * its a rewrite of code they already wrote in the openssl library. * most of it is trivial * your specific downstream needs are different than another downstream's project need, so in order to satisfy everyone they'll have to build a complete library. Which is basically a rewrite of what they already did. So, to rephrase the question, why would they spend time to propose a difficult to maintain, not really needed, potentially large yet trivial, doomed library? > > Did I miss something? > > Maybe you are striving for the wrong goal. It is not a goal to > clobber something together and encourage OpenSSL to repeat such > recklessness in the future, and leave users out in the rain once > again. I fully understand that the API change was/is difficult. Yet, it's a proactive move (and not a bad one) to enhance downstream code and to limit the impact of further changes. You don't have to micromanage a quadrillion of structure members with confused semantics, meaning that there is less chance to misuse them. Furthermore you no longer have access to what are are really implementation details. > It is not a goal either to create a shim that is not > officially audited and thoroughly tested by the original authors > who know their original code best, to create a shim that creates > additional dangers for security. We are talking about security > software here, so this is not the place at all to lightly cobble > something together, in particular not in ways involving many lines > of additional code. And I fully get that as well. But since nobody will step in, one has to do the job. Luckily, many has jumped in (and I was ready to do that as well). Their shim code is, as expected, quite clear and it should be easy to spot anything suspicious or wrong (I suspect some BN_free() should be replaced with BN_clear_free() here and there, but for most part the BN_free() directly comes from the openssl code). The fact is that most added functions are setters and getters, so until you do things in the Widely Wrong Way, it should be ok :) I'm not talking about rewrite RSA_public_encrypt() :) > If a few important projects keep up resistance and refuse support > for 1.1 until OpenSSL rolls up their sleeves and fixes the mess > they have created, maybe they will eventually realize that they > started a job here, wandered off half-way, and failed to ever > properly finish it. Or another, less important project that did the jump will replace it because distros have limited patience w.r.t. softwares that do not want to evolve their API. Once the 1.0.2 support is out, distros will want to have 1.1 and softwares that do not want to move to that version will either be patched or replaced. Other implementations already exist, including dropbear, GNU lsh and probably others I don't know. Most of them are not as good as openssh and some of them are downright horrible to use (I'm looking at you, GNU lsh...) but the fact that some alternatives exists is what's important here. You also must take into account that some people want to have openssl 1.1 for wahetever reason (for example, TLS1.3 support in 1.1.1). For them, having to cope with multiple versions of the openssl library is not going to work well. Distro maintainers will also be rightly pissed off if only one important program does not want to take the jump. > So, such resistance has a chance to improve the situation for > everybody. And i can't think of many projects that are in as > widespread use as OpenSSH, and hence can be more valuable with > respect to such resistance. I'm not sure it's practical in the long term. Furthermore, one cannot really expect that the openssl team will deprecate the 1.1 API and move back to the Good Ol' Days of the 1.0.1 API. I'm not saying that resistance is futile but I'm not sure it will have the desired effect. > > Just my personal 2 cents, > yours, > Ingo Best regards, -- Emmanuel Deloget (*) that does not mean openssl is not great. From doctor at doctor.nl2k.ab.ca Fri Jun 23 22:15:01 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 23 Jun 2017 06:15:01 -0600 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: <20170622232631.GD77030@athene.usta.de> Message-ID: <20170623121501.GB25500@doctor.nl2k.ab.ca> On Fri, Jun 23, 2017 at 01:53:24PM +0200, Emmanuel Deloget wrote: > Hello Ingo, > > On Fri, Jun 23, 2017 at 1:26 AM, Ingo Schwarze wrote: > > > > Hi Emmanuel, > > > > Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200: > > > > > * the openssl team has no real incentive to propose a shim ; > > > > If major application projects refuse to support their new release, > > thus putting pressure on operating system distributions to not > > completely switch to 1.1 either, that is not an incentive? > > Yes and no. The fact is that openssl is widely used by tons of projects. > Even if a major project quits (and frankly, these days openssh is built > around libressl, not openssl, so one car argue that openssh already leaved > the boat) there is little incentive for the openssl to not continue in the > same direction as other projects will follow anyway -- mostly because > openssl is openssl, not because openssl is great (*). > > Why would the openssl team do that ? > > * it's time consuming, and their time is better spent on enhancing the > security and features of the openssl libs > * such a project is doomed. It would make the various downstream project > move to the openssl 1.1 API, at which point the remaining distros will dump > older versions, meaning that the shim will have a life duration of one, > maybe two years. > * yet during these two years, it might become a stable (as introduces by > R.C. Martin : a stable software is one who as many clients and a limited > set of dependencies), meaning that every little change in it might have > tremendous effects on downstream projects. > * its a rewrite of code they already wrote in the openssl library. > * most of it is trivial > * your specific downstream needs are different than another downstream's > project need, so in order to satisfy everyone they'll have to build a > complete library. Which is basically a rewrite of what they already did. > > So, to rephrase the question, why would they spend time to propose a > difficult to maintain, not really needed, potentially large yet trivial, > doomed library? > > > > Did I miss something? > > > > Maybe you are striving for the wrong goal. It is not a goal to > > clobber something together and encourage OpenSSL to repeat such > > recklessness in the future, and leave users out in the rain once > > again. > > I fully understand that the API change was/is difficult. Yet, it's a > proactive move (and not a bad one) to enhance downstream code and to limit > the impact of further changes. You don't have to micromanage a quadrillion > of structure members with confused semantics, meaning that there is less > chance to misuse them. Furthermore you no longer have access to what are > are really implementation details. > > > It is not a goal either to create a shim that is not > > officially audited and thoroughly tested by the original authors > > who know their original code best, to create a shim that creates > > additional dangers for security. We are talking about security > > software here, so this is not the place at all to lightly cobble > > something together, in particular not in ways involving many lines > > of additional code. > > > And I fully get that as well. > > But since nobody will step in, one has to do the job. Luckily, many has > jumped in (and I was ready to do that as well). Their shim code is, as > expected, quite clear and it should be easy to spot anything suspicious or > wrong (I suspect some BN_free() should be replaced with BN_clear_free() > here and there, but for most part the BN_free() directly comes from the > openssl code). > > The fact is that most added functions are setters and getters, so until you > do things in the Widely Wrong Way, it should be ok :) I'm not talking about > rewrite RSA_public_encrypt() :) > > > If a few important projects keep up resistance and refuse support > > for 1.1 until OpenSSL rolls up their sleeves and fixes the mess > > they have created, maybe they will eventually realize that they > > started a job here, wandered off half-way, and failed to ever > > properly finish it. > > Or another, less important project that did the jump will replace it > because distros have limited patience w.r.t. softwares that do not want to > evolve their API. Once the 1.0.2 support is out, distros will want to have > 1.1 and softwares that do not want to move to that version will either be > patched or replaced. Other implementations already exist, including > dropbear, GNU lsh and probably others I don't know. Most of them are not as > good as openssh and some of them are downright horrible to use (I'm looking > at you, GNU lsh...) but the fact that some alternatives exists is what's > important here. > > You also must take into account that some people want to have openssl 1.1 > for wahetever reason (for example, TLS1.3 support in 1.1.1). For them, > having to cope with multiple versions of the openssl library is not going > to work well. Distro maintainers will also be rightly pissed off if only > one important program does not want to take the jump. > > > So, such resistance has a chance to improve the situation for > > everybody. And i can't think of many projects that are in as > > widespread use as OpenSSH, and hence can be more valuable with > > respect to such resistance. > > I'm not sure it's practical in the long term. Furthermore, one cannot > really expect that the openssl team will deprecate the 1.1 API and move > back to the Good Ol' Days of the 1.0.1 API. I'm not saying that resistance > is futile but I'm not sure it will have the desired effect. > Unfortunately, Openssl will not be heading that way. Opensl 1.0.X dies, that is it, Openssl 1.1.X upwards will be the standrard. Other packages like Exim, INN, Curl and Bind are adapating. Even Claamav will adapat, just a 2 line fix. In this case resistance will go nowhere. > > > Just my personal 2 cents, > > yours, > > Ingo > > > Best regards, > > -- Emmanuel Deloget > > (*) that does not mean openssl is not great. > _______________________________________________ > 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 Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Talk Sense to a fool and he calls you foolish - Euripides From deengert at gmail.com Sat Jun 24 05:16:40 2017 From: deengert at gmail.com (Douglas E Engert) Date: Fri, 23 Jun 2017 14:16:40 -0500 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: <20170623121501.GB25500@doctor.nl2k.ab.ca> References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> Message-ID: OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing a shim for OpenSSL-1.1, the OpenSC code has been converted to the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of defines and macros was written to support older versions of OpenSSL and Libressl. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h The nice part of this approach is when using OpenSSL-1.1 sc-ossl-compat.h does not do anything. It sole purpose to provide calls to the older APIs that are not going to change and eventually the sc-ossl-compat.h could be removed. Only the OpenSSL routines used by OpenSC have added to sc-ossl-compat.h but others defines and macro could be added.There are a few utilities that use still use a few #ifdef's during initialization. On 6/23/2017 7:15 AM, The Doctor wrote: > On Fri, Jun 23, 2017 at 01:53:24PM +0200, Emmanuel Deloget wrote: >> Hello Ingo, >> >> On Fri, Jun 23, 2017 at 1:26 AM, Ingo Schwarze wrote: >>> >>> Hi Emmanuel, >>> >>> Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200: >>> >>>> * the openssl team has no real incentive to propose a shim ; >>> >>> If major application projects refuse to support their new release, >>> thus putting pressure on operating system distributions to not >>> completely switch to 1.1 either, that is not an incentive? >> >> Yes and no. The fact is that openssl is widely used by tons of projects. >> Even if a major project quits (and frankly, these days openssh is built >> around libressl, not openssl, so one car argue that openssh already leaved >> the boat) there is little incentive for the openssl to not continue in the >> same direction as other projects will follow anyway -- mostly because >> openssl is openssl, not because openssl is great (*). >> >> Why would the openssl team do that ? >> >> * it's time consuming, and their time is better spent on enhancing the >> security and features of the openssl libs >> * such a project is doomed. It would make the various downstream project >> move to the openssl 1.1 API, at which point the remaining distros will dump >> older versions, meaning that the shim will have a life duration of one, >> maybe two years. >> * yet during these two years, it might become a stable (as introduces by >> R.C. Martin : a stable software is one who as many clients and a limited >> set of dependencies), meaning that every little change in it might have >> tremendous effects on downstream projects. >> * its a rewrite of code they already wrote in the openssl library. >> * most of it is trivial >> * your specific downstream needs are different than another downstream's >> project need, so in order to satisfy everyone they'll have to build a >> complete library. Which is basically a rewrite of what they already did. >> >> So, to rephrase the question, why would they spend time to propose a >> difficult to maintain, not really needed, potentially large yet trivial, >> doomed library? >> >>>> Did I miss something? >>> >>> Maybe you are striving for the wrong goal. It is not a goal to >>> clobber something together and encourage OpenSSL to repeat such >>> recklessness in the future, and leave users out in the rain once >>> again. >> >> I fully understand that the API change was/is difficult. Yet, it's a >> proactive move (and not a bad one) to enhance downstream code and to limit >> the impact of further changes. You don't have to micromanage a quadrillion >> of structure members with confused semantics, meaning that there is less >> chance to misuse them. Furthermore you no longer have access to what are >> are really implementation details. >> >>> It is not a goal either to create a shim that is not >>> officially audited and thoroughly tested by the original authors >>> who know their original code best, to create a shim that creates >>> additional dangers for security. We are talking about security >>> software here, so this is not the place at all to lightly cobble >>> something together, in particular not in ways involving many lines >>> of additional code. >> >> >> And I fully get that as well. >> >> But since nobody will step in, one has to do the job. Luckily, many has >> jumped in (and I was ready to do that as well). Their shim code is, as >> expected, quite clear and it should be easy to spot anything suspicious or >> wrong (I suspect some BN_free() should be replaced with BN_clear_free() >> here and there, but for most part the BN_free() directly comes from the >> openssl code). >> >> The fact is that most added functions are setters and getters, so until you >> do things in the Widely Wrong Way, it should be ok :) I'm not talking about >> rewrite RSA_public_encrypt() :) >> >>> If a few important projects keep up resistance and refuse support >>> for 1.1 until OpenSSL rolls up their sleeves and fixes the mess >>> they have created, maybe they will eventually realize that they >>> started a job here, wandered off half-way, and failed to ever >>> properly finish it. >> >> Or another, less important project that did the jump will replace it >> because distros have limited patience w.r.t. softwares that do not want to >> evolve their API. Once the 1.0.2 support is out, distros will want to have >> 1.1 and softwares that do not want to move to that version will either be >> patched or replaced. Other implementations already exist, including >> dropbear, GNU lsh and probably others I don't know. Most of them are not as >> good as openssh and some of them are downright horrible to use (I'm looking >> at you, GNU lsh...) but the fact that some alternatives exists is what's >> important here. >> >> You also must take into account that some people want to have openssl 1.1 >> for wahetever reason (for example, TLS1.3 support in 1.1.1). For them, >> having to cope with multiple versions of the openssl library is not going >> to work well. Distro maintainers will also be rightly pissed off if only >> one important program does not want to take the jump. >> >>> So, such resistance has a chance to improve the situation for >>> everybody. And i can't think of many projects that are in as >>> widespread use as OpenSSH, and hence can be more valuable with >>> respect to such resistance. >> >> I'm not sure it's practical in the long term. Furthermore, one cannot >> really expect that the openssl team will deprecate the 1.1 API and move >> back to the Good Ol' Days of the 1.0.1 API. I'm not saying that resistance >> is futile but I'm not sure it will have the desired effect. >> > > Unfortunately, Openssl will not be heading that way. > > Opensl 1.0.X dies, that is it, Openssl 1.1.X upwards will be the standrard. > > Other packages like Exim, INN, Curl and Bind are adapating. > > Even Claamav will adapat, just a 2 line fix. > > In this case resistance will go nowhere. > > > >>> Just my personal 2 cents, >>> yours, >>> Ingo >> >> >> Best regards, >> >> -- Emmanuel Deloget >> >> (*) that does not mean openssl is not great. >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert From andrew.darqui at gmail.com Sat Jun 24 15:17:42 2017 From: andrew.darqui at gmail.com (Andrew Darqui) Date: Sat, 24 Jun 2017 01:17:42 -0400 Subject: [patch] Typos, grammar, formatting in openssh-portable master Message-ID: Hi everyone. Nothing special, just a few typo fixes. Also, there's a typo on this page: https://www.openssh.com/list.html s/approriate/appropriate Thanks diff --git a/INSTALL b/INSTALL index 92106bf0..bfaad6c9 100644 --- a/INSTALL +++ b/INSTALL @@ -25,9 +25,9 @@ OpenSSL 1.1.x is not currently supported. The remaining items are optional. -NB. If you operating system supports /dev/random, you should configure +NB. If your operating system supports /dev/random, you should configure libcrypto (LibreSSL/OpenSSL) to use it. OpenSSH relies on libcrypto's -direct support of /dev/random, or failing that, either prngd or egd +direct support of /dev/random, or failing that, either prngd or egd. PRNGD: @@ -46,7 +46,7 @@ http://egd.sourceforge.net/ PAM: OpenSSH can utilise Pluggable Authentication Modules (PAM) if your -system supports it. PAM is standard most Linux distributions, Solaris, +system supports it. PAM is standard in most Linux distributions, Solaris, HP-UX 11, AIX >= 5.2, FreeBSD and NetBSD. Information about the various PAM implementations are available: @@ -99,7 +99,7 @@ http://www.gnu.org/software/autoconf/ Basic Security Module (BSM): -Native BSM support is know to exist in Solaris from at least 2.5.1, +Native BSM support is known to exist in Solaris from at least 2.5.1, FreeBSD 6.1 and OS X. Alternatively, you may use the OpenBSM implementation (http://www.openbsm.org). @@ -177,7 +177,7 @@ it if lastlog is installed in a different place. --without-lastlog will disable lastlog support entirely. --with-osfsia, --without-osfsia will enable or disable OSF1's Security -Integration Architecture. The default for OSF1 machines is enable. +Integration Architecture. The default for OSF1 machines is enabled. --with-skey=PATH will enable S/Key one time password support. You will need the S/Key libraries and header files installed for this to work. @@ -201,13 +201,12 @@ started by sshd. This replaces the standard path entirely. --with-pid-dir=PATH specifies the directory in which the sshd.pid file is created. ---with-xauth=PATH specifies the location of the xauth binary +--with-xauth=PATH specifies the location of the xauth binary. --with-ssl-dir=DIR allows you to specify where your Libre/OpenSSL -libraries -are installed. +libraries are installed. ---with-ssl-engine enables Libre/OpenSSL's (hardware) ENGINE support +--with-ssl-engine enables Libre/OpenSSL's (hardware) ENGINE support. --with-4in6 Check for IPv4 in IPv6 mapped addresses and convert them to real (AF_INET) IPv4 addresses. Works around some quirks on Linux. From ggarner_online at gmgsystemsinc.com Sat Jun 24 22:06:15 2017 From: ggarner_online at gmgsystemsinc.com (George M. Garner Jr.) Date: Sat, 24 Jun 2017 08:06:15 -0400 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> Message-ID: <38b93c06-4996-7fa1-4812-9fb3f6a15637@gmgsystemsinc.com> I think that this is the better approach. The question I have is why the SSH logic should be dependent on the implementation details of ANY particular cryptographic library (be it openssl, libressl or whatever)? Proper software design would develop an abstraction layer with some measure of forward compatibility built in. On 6/23/2017 3:16 PM, Douglas E Engert wrote: > OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing > a shim for OpenSSL-1.1, the OpenSC code has been converted to > the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of defines and > macros was written to support older versions of OpenSSL and Libressl. > > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h > > The nice part of this approach is when using OpenSSL-1.1 sc-ossl-compat.h > does not do anything. It sole purpose to provide calls to the older APIs > that are not going to change and eventually the sc-ossl-compat.h could be > removed. > From schwarze at usta.de Sun Jun 25 01:16:52 2017 From: schwarze at usta.de (Ingo Schwarze) Date: Sat, 24 Jun 2017 17:16:52 +0200 Subject: [patch] Typos, grammar, formatting in openssh-portable master In-Reply-To: References: Message-ID: <20170624151652.GJ39761@athene.usta.de> Hi Andrew, Andrew Darqui wrote on Sat, Jun 24, 2017 at 01:17:42AM -0400: > Hi everyone. Nothing special, just a few typo fixes. Committing the INSTALL fixes is still an open task. > Also, there's a typo on this page: https://www.openssh.com/list.html > s/approriate/appropriate I committed that one. Thanks, Ingo > diff --git a/INSTALL b/INSTALL > index 92106bf0..bfaad6c9 100644 > --- a/INSTALL > +++ b/INSTALL > @@ -25,9 +25,9 @@ OpenSSL 1.1.x is not currently supported. > > The remaining items are optional. > > -NB. If you operating system supports /dev/random, you should configure > +NB. If your operating system supports /dev/random, you should configure > libcrypto (LibreSSL/OpenSSL) to use it. OpenSSH relies on libcrypto's > -direct support of /dev/random, or failing that, either prngd or egd > +direct support of /dev/random, or failing that, either prngd or egd. > > PRNGD: > > @@ -46,7 +46,7 @@ http://egd.sourceforge.net/ > PAM: > > OpenSSH can utilise Pluggable Authentication Modules (PAM) if your > -system supports it. PAM is standard most Linux distributions, Solaris, > +system supports it. PAM is standard in most Linux distributions, Solaris, > HP-UX 11, AIX >= 5.2, FreeBSD and NetBSD. > > Information about the various PAM implementations are available: > @@ -99,7 +99,7 @@ http://www.gnu.org/software/autoconf/ > > Basic Security Module (BSM): > > -Native BSM support is know to exist in Solaris from at least 2.5.1, > +Native BSM support is known to exist in Solaris from at least 2.5.1, > FreeBSD 6.1 and OS X. Alternatively, you may use the OpenBSM > implementation (http://www.openbsm.org). > > @@ -177,7 +177,7 @@ it if lastlog is installed in a different place. > --without-lastlog will disable lastlog support entirely. > > --with-osfsia, --without-osfsia will enable or disable OSF1's Security > -Integration Architecture. The default for OSF1 machines is enable. > +Integration Architecture. The default for OSF1 machines is enabled. > > --with-skey=PATH will enable S/Key one time password support. You will > need the S/Key libraries and header files installed for this to work. > @@ -201,13 +201,12 @@ started by sshd. This replaces the standard path > entirely. > --with-pid-dir=PATH specifies the directory in which the sshd.pid file is > created. > > ---with-xauth=PATH specifies the location of the xauth binary > +--with-xauth=PATH specifies the location of the xauth binary. > > --with-ssl-dir=DIR allows you to specify where your Libre/OpenSSL > -libraries > -are installed. > +libraries are installed. > > ---with-ssl-engine enables Libre/OpenSSL's (hardware) ENGINE support > +--with-ssl-engine enables Libre/OpenSSL's (hardware) ENGINE support. > > --with-4in6 Check for IPv4 in IPv6 mapped addresses and convert them to > real (AF_INET) IPv4 addresses. Works around some quirks on Linux. From logout at free.fr Sun Jun 25 02:02:32 2017 From: logout at free.fr (Emmanuel Deloget) Date: Sat, 24 Jun 2017 18:02:32 +0200 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: <38b93c06-4996-7fa1-4812-9fb3f6a15637@gmgsystemsinc.com> References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> <38b93c06-4996-7fa1-4812-9fb3f6a15637@gmgsystemsinc.com> Message-ID: Hi George, On Sat, Jun 24, 2017 at 2:06 PM, George M. Garner Jr. wrote: > I think that this is the better approach. The question I have is why the > SSH logic should be dependent on the implementation details of ANY > particular cryptographic library (be it openssl, libressl or whatever)? > Proper software design would develop an abstraction layer with some measure > of forward compatibility built in. I'm all in favor of abstracting such a complex piece of code. Yet the sheer number of available crypto library out there makes it an XKCD "build another standard to aggregate all the existing standard, so now there is one more standard to deal with" kind of situation. Not to mention that these libraries may implement different philosophies so building some abstraction code above them could be quite complex. To be honest, I would not even know where to start :) BR, -- Emmanuel Deloget From logout at free.fr Sun Jun 25 02:35:52 2017 From: logout at free.fr (Emmanuel Deloget) Date: Sat, 24 Jun 2017 18:35:52 +0200 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> Message-ID: Hello Douglas, On Fri, Jun 23, 2017 at 9:16 PM, Douglas E Engert wrote: > OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing > a shim for OpenSSL-1.1, the OpenSC code has been converted to > the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of defines and > macros was written to support older versions of OpenSSL and Libressl. > > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h > > The nice part of this approach is when using OpenSSL-1.1 sc-ossl-compat.h > does not do anything. It sole purpose to provide calls to the older APIs > that are not going to change and eventually the sc-ossl-compat.h could be > removed. > > Only the OpenSSL routines used by OpenSC have added to sc-ossl-compat.h > but others defines and macro could be added.There are a few utilities that > use still use a few #ifdef's during initialization. This might be because I'm kind of a failure when I try to speak English but this is what I assumed to be a shim :) Of course, I might be wrong again :) This is very similar to the approach taken by Kurt in his patch and to the work I did for OpenVPN ? [1]? . And I also think it's the way to go since it will allow to diss older versions of openssl and/or libressl with minimal change in the Code That Matters while not being terribly difficult to maintain. According to Kurt's patch, such a compat file for openssh would clock at roughly 500 lines of nearly trivial code (and I insist on this fact: code is quite trivial. The most complicated function would be this one : ?----8<-----? static int EVP_MD_CTX_reset(EVP_MD_CTX *ctx) { ? ? if (ctx == NULL) ? ? return 1; ? ? /* ? ? * Don't assume ctx->md_data was cleaned in EVP_Digest_Final, because ? ? * sometimes only copies of the context are ever finalised. ? ? */ ? ? if (ctx->digest && ctx->digest->cleanup ? ? && !EVP_MD_CTX_test_flags(ctx, EVP_MD_CTX_FLAG_CLEANED)) ? ? ctx->digest->cleanup(ctx); ? ? if (ctx->digest && ctx->digest->ctx_size && ctx->md_data ? ? && !EVP_MD_CTX_test_flags(ctx, EVP_MD_CTX_FLAG_REUSE)) { ? ? OPENSSL_clear_free(ctx->md_data, ctx->digest->ctx_size); ? ? } ? ? EVP_PKEY_CTX_free(ctx->pctx); #ifndef OPENSSL_NO_ENGINE ? ? ENGINE_finish(ctx->engine); #endif ? ? OPENSSL_cleanse(ctx, sizeof(*ctx)); ? ? return 1; } ?---->8----- Other functions are getter and setters such as : ?----8<-----? void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key) { if (pub_key != NULL) *pub_key = dh->pub_key; if (priv_key != NULL) *priv_key = dh->priv_key; } int DH_set0_key(DH *dh, BIGNUM *pub_key, BIGNUM *priv_key) { /* If the field pub_key in dh is NULL, the corresponding input * parameters MUST be non-NULL. The priv_key field may * be left NULL. */ if (dh->pub_key == NULL && pub_key == NULL) return 0; if (pub_key != NULL) { BN_free(dh->pub_key); dh->pub_key = pub_key; } if (priv_key != NULL) { BN_free(dh->priv_key); dh->priv_key = priv_key; } return 1; } ?int RSA_bits(const RSA *r) { return (BN_num_bits(r->n)); } ?---->8----- There are some simple security?-related functions such as OPENSSL_zalloc() or OPENSSL_clean_free() but these functions are quite simple too (and the reasoning behind them is, I assume, well known). BR, -- Emmanuel Deloget ?[1] https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/openssl_compat.h ? From deengert at gmail.com Sun Jun 25 04:09:08 2017 From: deengert at gmail.com (Douglas E Engert) Date: Sat, 24 Jun 2017 13:09:08 -0500 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> Message-ID: <0ff7103a-16cb-0710-e8b3-956cdbd0098b@gmail.com> On 6/24/2017 11:35 AM, Emmanuel Deloget wrote: > Hello Douglas, > > On Fri, Jun 23, 2017 at 9:16 PM, Douglas E Engert > wrote: > > OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing > > a shim for OpenSSL-1.1, the OpenSC code has been converted to > > the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of defines and > > macros was written to support older versions of OpenSSL and Libressl. > > > > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h > > > > The nice part of this approach is when using OpenSSL-1.1 sc-ossl-compat.h > > does not do anything. It sole purpose to provide calls to the older APIs > > that are not going to change and eventually the sc-ossl-compat.h could be > > removed. > > > > Only the OpenSSL routines used by OpenSC have added to sc-ossl-compat.h > > but others defines and macro could be added.There are a few utilities that > > use still use a few #ifdef's during initialization. > > This might be because I'm kind of a failure when I try to speak English but this is what I assumed to be a shim :) Of course, I might be wrong again :) Yes it is a shim. https://en.wikipedia.org/wiki/Shim_(computing) "Shims can be used to support an old API in a newer environment, or a new API in an older environment." My reading of the discussion was to keep the older API to avoid changing the OpenSSH code so a shim would be to support an "old API in a newer environment(OpenSSL-1.1)". What we did was to convert OpenSC to the OpenSSL-1.1 API the write the shim for "new API in an older environment". Looking at your openssl_compat.h it looks like you have done something similar. With OpenSC we only added the routines and defines we needed in OpenSC. > > This is very similar to the approach taken by Kurt in his patch and to the work I did for OpenVPN > ? [1]? > . And I also think it's the way to go since it will allow to diss older versions of openssl and/or libressl with minimal change in the Code That Matters while not being terribly difficult to maintain. > According to Kurt's patch, such a compat file for openssh would clock at roughly 500 lines of nearly trivial code (and I insist on this fact: code is quite trivial. The most complicated function would > be this one : > > ?----8<-----? > static int EVP_MD_CTX_reset(EVP_MD_CTX *ctx) > { > ?? > if (ctx == NULL) > ?? > return 1; > ?? > /* > ?? > * Don't assume ctx->md_data was cleaned in EVP_Digest_Final, because > ?? > * sometimes only copies of the context are ever finalised. > ?? > */ > ?? > if (ctx->digest && ctx->digest->cleanup > ?? > && !EVP_MD_CTX_test_flags(ctx, EVP_MD_CTX_FLAG_CLEANED)) > ?? > ctx->digest->cleanup(ctx); > ?? > if (ctx->digest && ctx->digest->ctx_size && ctx->md_data > ?? > && !EVP_MD_CTX_test_flags(ctx, EVP_MD_CTX_FLAG_REUSE)) { > ?? > OPENSSL_clear_free(ctx->md_data, ctx->digest->ctx_size); > ?? > } > ?? > EVP_PKEY_CTX_free(ctx->pctx); > #ifndef OPENSSL_NO_ENGINE > ?? > ENGINE_finish(ctx->engine); > #endif > ?? > OPENSSL_cleanse(ctx, sizeof(*ctx)); > > ?? > return 1; > } > ?---->8----- > > > Other functions are getter and setters such as : > > ?----8<-----? > void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key) > { > if (pub_key != NULL) > *pub_key = dh->pub_key; > if (priv_key != NULL) > *priv_key = dh->priv_key; > } > > int DH_set0_key(DH *dh, BIGNUM *pub_key, BIGNUM *priv_key) > { > /* If the field pub_key in dh is NULL, the corresponding input > * parameters MUST be non-NULL. The priv_key field may > * be left NULL. > */ > if (dh->pub_key == NULL && pub_key == NULL) > return 0; > > if (pub_key != NULL) { > BN_free(dh->pub_key); > dh->pub_key = pub_key; > } > if (priv_key != NULL) { > BN_free(dh->priv_key); > dh->priv_key = priv_key; > } > > return 1; > } > > ?int RSA_bits(const RSA *r) > { > return (BN_num_bits(r->n)); > } > ?---->8----- > > > There are some simple security?-related functions such as OPENSSL_zalloc() or OPENSSL_clean_free() but these functions are quite simple too (and the reasoning behind them is, I assume, well known). > > > BR, > > -- Emmanuel Deloget > > ?[1] https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/openssl_compat.h > ? -- Douglas E. Engert From stu at spacehopper.org Sun Jun 25 19:47:26 2017 From: stu at spacehopper.org (Stuart Henderson) Date: Sun, 25 Jun 2017 09:47:26 +0000 (UTC) Subject: OpenSSL 1.1 support status : what next? References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> <0ff7103a-16cb-0710-e8b3-956cdbd0098b@gmail.com> Message-ID: On 2017-06-24, Douglas E Engert wrote: > My reading of the discussion was to keep the older API to avoid changing the > OpenSSH code so a shim would be to support an "old API in a newer environment(OpenSSL-1.1)". Exactly the other way round. Since it seems 1.0.x is going to be around for some years yet until RHEL7 is end-of-life, there's clearly a need for downstream projects to work with multiple OpenSSL versions. Many projects have been handling the conversion with #ifdef'd compatibility code, which is hard to read and hard to test. (As a packager for an OS using LibreSSL this is very obvious as these almost all check OPENSSL_VERSION_NUMBER and need changes for LibreSSL). It's obvious why people have been taking this approach - it has long been the usual approach to deal with new functions being introduced in the OpenSSL API. It's not quite so messy when using it to disable certain features not yet supported, but using it for whole parallel codepaths gets a lot more confusing (and diffs get rather hard to review). Additionally it seems like some of this code (especially for smaller projects) has come from users not especially familiar with either the downstream code *or* OpenSSL, whose main motivation is to unbreak build for OS that are using 1.1, and are less interested in 1.0.x. > What we did was to convert OpenSC to the OpenSSL-1.1 API the write the shim > for "new API in an older environment". > > Looking at your openssl_compat.h it looks like you have done something similar. > With OpenSC we only added the routines and defines we needed in OpenSC. Using shims like this and writing to the new API seems exactly the right approach, and is similar to what OpenSSH-portable has done successfully for years. But isn't it silly that each project wanting to support both old+new OpenSSL has to maintain their own shim? This would all be a lot simpler for downstream projects if there was a single trusted source for such a shim, coming from people familiar with the OpenSSL code. Then those downstream projects (who know their *own* code well) can treat it as a simple API change and not have to worry about compatibility. From deengert at gmail.com Sun Jun 25 21:58:55 2017 From: deengert at gmail.com (Douglas E Engert) Date: Sun, 25 Jun 2017 06:58:55 -0500 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> <0ff7103a-16cb-0710-e8b3-956cdbd0098b@gmail.com> Message-ID: On 6/25/2017 4:47 AM, Stuart Henderson wrote: > On 2017-06-24, Douglas E Engert wrote: >> My reading of the discussion was to keep the older API to avoid changing the >> OpenSSH code so a shim would be to support an "old API in a newer environment(OpenSSL-1.1)". > > Exactly the other way round. Upon further review, I stand corrected. OpenSC's approach [1] is similar to the examples in this thread. > > Since it seems 1.0.x is going to be around for some years yet until > RHEL7 is end-of-life, there's clearly a need for downstream projects > to work with multiple OpenSSL versions. > > Many projects have been handling the conversion with #ifdef'd > compatibility code, which is hard to read and hard to test. (As a > packager for an OS using LibreSSL this is very obvious as these almost > all check OPENSSL_VERSION_NUMBER and need changes for LibreSSL). > > It's obvious why people have been taking this approach - it has long > been the usual approach to deal with new functions being introduced > in the OpenSSL API. It's not quite so messy when using it to disable > certain features not yet supported, but using it for whole parallel > codepaths gets a lot more confusing (and diffs get rather hard to > review). > > Additionally it seems like some of this code (especially for smaller > projects) has come from users not especially familiar with either the > downstream code *or* OpenSSL, whose main motivation is to unbreak build > for OS that are using 1.1, and are less interested in 1.0.x. > >> What we did was to convert OpenSC to the OpenSSL-1.1 API the write the shim >> for "new API in an older environment". >> >> Looking at your openssl_compat.h it looks like you have done something similar. >> With OpenSC we only added the routines and defines we needed in OpenSC. Yes, supports multiple OpenSSL and LibreSSL. > > Using shims like this and writing to the new API seems exactly the right > approach, and is similar to what OpenSSH-portable has done successfully > for years. But isn't it silly that each project wanting to support both > old+new OpenSSL has to maintain their own shim? Yes, but to OpenSSL's credit, they have been moving in this direction, in previous releases, with adding macros or routines to do move away from direct access to what are now hidden structures. But they have now forced the use of these new routines and additional hidden structures in 1.1. > > This would all be a lot simpler for downstream projects if there was a > single trusted source for such a shim, coming from people familiar with > the OpenSSL code. Then those downstream projects (who know their *own* > code well) can treat it as a simple API change and not have to worry > about compatibility. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > [1] https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h -- Douglas E. Engert From ggarner_online at gmgsystemsinc.com Mon Jun 26 09:47:28 2017 From: ggarner_online at gmgsystemsinc.com (George M. Garner Jr.) Date: Sun, 25 Jun 2017 19:47:28 -0400 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> <38b93c06-4996-7fa1-4812-9fb3f6a15637@gmgsystemsinc.com> Message-ID: <962bae6d-d587-b705-29b7-996b00a4fe71@gmgsystemsinc.com> Emmanuel, The task becomes an "XKCD problem" only because you define the problem in terms of support for every conceivable crypto library. In practice there are only libraries a few in common use with SSH (e.g. openssl, libressl). If you define the task in terms of providing an abstraction that is able to support these common crypto libraries (with some measure of forward compatiblity) the task becomes more manageable. In most cases a crypto api function can be defined in terms of an opaque state variable, a state type variable, input, input size, output, output size and a return value. Any thing would be better than having #ifdef's scattered throughout the code. Regards, George. From aris at 0xbadc0de.be Tue Jun 27 05:16:46 2017 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Mon, 26 Jun 2017 21:16:46 +0200 Subject: OpenSSL 1.1 support status : what next? In-Reply-To: <38b93c06-4996-7fa1-4812-9fb3f6a15637@gmgsystemsinc.com> References: <20170622232631.GD77030@athene.usta.de> <20170623121501.GB25500@doctor.nl2k.ab.ca> <38b93c06-4996-7fa1-4812-9fb3f6a15637@gmgsystemsinc.com> Message-ID: <17fd5c4b-e748-6e13-6b63-fa655e453e90@0xbadc0de.be> Having done this with libssh, this is far from trivial, even for the rather simple primitives required by SSH. Abstracting some concepts across very different libraries that deal with them in different ways (e.g. libcrypto vs libgcrypt) can introduce some nasty bugs. OpenSSH has always had KISS in mind so I wouldn't blame them to avoid supporting additional libraries or dropping OpenSSL 1.1 and sticking to LibreSSL altogether. On the subject of OpenSSL, Jakub Jelen provided us with an OpenSSL1.1-to-1.0 shim that works, but is not free of bugs. I would have definitively have appreciated that OpenSSL wrote that shim by themselves (they say it's trivial, of course it is not). The big problem currently is that any application that does nontrivial low-level cryptography cannot use a single API that will work with both of them, they're 100% incompatible. Aris On 24/06/17 14:06, George M. Garner Jr. wrote: > I think that this is the better approach. The question I have is why > the SSH logic should be dependent on the implementation details of ANY > particular cryptographic library (be it openssl, libressl or > whatever)? Proper software design would develop an abstraction layer > with some measure of forward compatibility built in. > > On 6/23/2017 3:16 PM, Douglas E Engert wrote: >> OpenSC has taken a different approach to OpenSSL-1.1. Rather then >> writing >> a shim for OpenSSL-1.1, the OpenSC code has been converted to >> the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of >> defines and >> macros was written to support older versions of OpenSSL and Libressl. >> >> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h >> >> >> The nice part of this approach is when using OpenSSL-1.1 >> sc-ossl-compat.h >> does not do anything. It sole purpose to provide calls to the older APIs >> that are not going to change and eventually the sc-ossl-compat.h >> could be >> removed. >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jreiser at bitwagon.com Fri Jun 30 01:58:56 2017 From: jreiser at bitwagon.com (John Reiser) Date: Thu, 29 Jun 2017 08:58:56 -0700 Subject: [patch] mention legacy.html web page on ssh manual page Message-ID: Please enhance the Usability of the manual page documentation for ssh by mentioning https://www.openssh.com/legacy.html. This would have saved me time discovering how to interoperate with old implementations. The attached patch also cross-references the -G and -Q command-line options. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-7.4p1-legacy.patch Type: text/x-patch Size: 680 bytes Desc: not available URL: