Call for testing: OpenSSH 8.5
20 views
Skip to first unread message
Damien Miller
Feb 22, 2021, 8:49:22 PM2/22/21
to openssh-...@mindrot.org
Hi,
OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a bugfix release.
Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/
The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html
Portable OpenSSH is also available via git using the
instructions at http://www.openssh.com/portable.html#cvs
At https://anongit.mindrot.org/openssh.git/ or via a mirror at Github:
https://github.com/openssh/openssh-portable
Running the regression tests supplied with Portable OpenSSH does not
require installation and is a simply:
$ ./configure && make tests
Live testing on suitable non-production systems is also appreciated.
Please send reports of success or failure to
openssh-...@mindrot.org. Security bugs should be reported
directly to ope...@openssh.com.
Below is a summary of changes. More detail may be found in the ChangeLog
in the portable OpenSSH tarballs.
Thanks to the many people who contributed to this release.
Security
========
* Portable sshd(8): Prevent excessively long username going to PAM.
This is a mitigation for a buffer overflow in Solaris' PAM username
handling (CVE-2020-14871), and is only enabled for Sun-derived PAM
implementations. This is not a problem in sshd itself, it only
prevents sshd from being used as a vector to attack Solaris' PAM.
It does not prevent the bug in PAM from being exploited via some
other PAM application. GHPR#212
Potentially-incompatible changes
================================
This release includes a number of changes that may affect existing
configurations:
* ssh(1), sshd(8): this release changes the first-preference signature
algorithm from ECDSA to ED25519.
* ssh(1), sshd(8): set the TOS/DSCP specified in the configuration
for interactive use prior to TCP connect. The connection phase of
the SSH session is time-sensitive and often explicitly interactive.
The ultimate interactive/bulk TOS/DSCP will be set after
authentication completes.
* ssh(1), sshd(8): remove the pre-standardization cipher
rijnda...@lysator.liu.se. It is an alias for aes256-cbc before
it was standardized in RFC4253 (2006), has been deprecated and
disabled by default since OpenSSH 7.2 (2016) and was only briefly
documented in ssh.1 in 2001.
* ssh(1), sshd(8): update/replace the experimental post-quantum
hybrid key exchange method based on Streamlined NTRU Prime coupled
with X25519.
The previous sntrup4591761...@tinyssh.org method is
replaced with sntrup761x2...@openssh.com. Per its
designers, the sntrup4591761 algorithm was superseded almost two
years ago by sntrup761.
(note this both the updated method and the one that it replaced are
disabled by default)
* ssh(1): disable CheckHostIP by default. It provides insignificant
benefits while making key rotation significantly more difficult,
especially for hosts behind IP-based load-balancers.
Changes since OpenSSH 8.4
=========================
New features
------------
* ssh(1): this release enables UpdateHostkeys by default subject to
some conservative preconditions:
- The key was matched in the UserKnownHostsFile (and not in the
GlobalKnownHostsFile).
- The same key does not exist under another name.
- A certificate host key is not in use.
- known_hosts contains no matching wildcard hostname pattern.
- VerifyHostKeyDNS is not enabled.
We expect some of these conditions will be modified or relaxed in
future.
* ssh(1), sshd(8): add a new LogVerbose configuration directive for
that allows forcing maximum debug logging by file/function/line
pattern-lists.
* ssh(1): when prompting the user to accept a new hostkey, display
any other host names/addresses already associated with the key.
* ssh(1): allow UserKnownHostsFile=none to indicate that no
known_hosts file should be used to identify host keys.
* ssh(1): add a ssh_config KnownHostsCommand that allows the client
to obtain known_hosts data from a command in addition to the usual
files.
* ssh(1): for FIDO keys, if a signature operation fails with a
"incorrect PIN" reason and no PIN was initially requested from the
user, then request a PIN and retry the operation. This supports
some biometric devices that fall back to requiring PIN when reading
of the biometric failed, and devices that require PINs for all
hosted credentials.
* sshd(8): implement client address-based rate-limiting via new
sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize
directives that fine-grained control than the global MaxStartups
limit.
Bugfixes
--------
* ssh(1): Prefix keyboard interactive prompts with "(user@host)" to
make it easier to determine which connection they are associated
with in cases like scp -3, ProxyJump, etc. bz#3224
* sshd(8): fix sshd_config SetEnv directives located inside Match
blocks. GHPR#201
* ssh(1): when requesting a FIDO token touch on stderr, inform the
user once the touch has been recorded.
* ssh(1): prevent integer overflow when ridiculously large
ConnectTimeout values are specified, capping the effective value
(for most platforms) at 24 days. bz#3229
* ssh(1): consider the ECDSA key subtype when ordering host key
algorithms in the client,
* ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
that it control allowed key algorithms, when this option actually
specifies the signature algorithms that are accepted. The previous
name remains available as an alias. bz#3253
* ssh(1), sshd(8): similarly, rename HostbasedKeyTypes (ssh) and
HostbasedAcceptedKeyTypes (sshd) to HostbasedAcceptedAlgorithms.
* sftp-server(8): add missing lset...@openssh.com documentation
and advertisement in the server's SSH2_FXP_VERSION hello packet.
* ssh(1), sshd(8): more strictly enforce KEX state-machine by
banning packet types once they are received. Fixes memleak caused
by duplicate SSH2_MSG_KEX_DH_GEX_REQUEST (oss-fuzz #30078).
* sftp(1): allow the full range of UIDs/GIDs for chown/chgrp on 32bit
platforms instead of being limited by LONG_MAX. bz#3206
* Minor man page fixes (capitalization, commas, etc.) bz#3223
* sftp(1): when doing an sftp recursive upload or download of a
read-only directory, ensure that the directory is created with
write and execute permissions in the interim so that the transfer
can actually complete, then set the directory permission as the
final step. bz#3222
* ssh-keygen(1): document the -Z, check the validity of its argument
earlier and provide a better error message if it's not correct.
bz#2879
* ssh(1): ignore comments at the end of config lines in ssh_config,
similar to what we already do for sshd_config. bz#2320
* sshd_config(5): mention that DisableForwarding is valid in a
sshd_config Match block. bz3239
* sftp(1): fix incorrect sorting of "ls -ltr" under some
circumstances. bz3248.
* ssh(1), sshd(8): fix potential integer truncation of (unlikely)
timeout values. bz#3250
* ssh(1): make hostbased authentication send the signature algorithm
in its SSH2_MSG_USERAUTH_REQUEST packets instead of the key type.
This make HostbasedAcceptedAlgorithms do what it is supposed to -
filter on signature algorithm and not key type.
Portability
-----------
* sshd(8): add a number of platform-specific syscalls to the Linux
seccomp-bpf sandbox. bz#3232 bz#3260
* sshd(8): remove debug message from sigchld handler that could cause
deadlock on some platforms. bz#3259
* Sync contrib/ssh-copy-id with upstream.
* unittests: add a hostname function for systems that don't have it.
Some systems don't have a hostname command (it's not required by
POSIX). The do have uname -n (which is), but not all of those have
it report the FQDN.
OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de
Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre,
Tim Rice and Ben Lindstrom.
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a bugfix release.
Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/
The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html
Portable OpenSSH is also available via git using the
instructions at http://www.openssh.com/portable.html#cvs
At https://anongit.mindrot.org/openssh.git/ or via a mirror at Github:
https://github.com/openssh/openssh-portable
Running the regression tests supplied with Portable OpenSSH does not
require installation and is a simply:
$ ./configure && make tests
Live testing on suitable non-production systems is also appreciated.
Please send reports of success or failure to
openssh-...@mindrot.org. Security bugs should be reported
directly to ope...@openssh.com.
Below is a summary of changes. More detail may be found in the ChangeLog
in the portable OpenSSH tarballs.
Thanks to the many people who contributed to this release.
Security
========
* Portable sshd(8): Prevent excessively long username going to PAM.
This is a mitigation for a buffer overflow in Solaris' PAM username
handling (CVE-2020-14871), and is only enabled for Sun-derived PAM
implementations. This is not a problem in sshd itself, it only
prevents sshd from being used as a vector to attack Solaris' PAM.
It does not prevent the bug in PAM from being exploited via some
other PAM application. GHPR#212
Potentially-incompatible changes
================================
This release includes a number of changes that may affect existing
configurations:
* ssh(1), sshd(8): this release changes the first-preference signature
algorithm from ECDSA to ED25519.
* ssh(1), sshd(8): set the TOS/DSCP specified in the configuration
for interactive use prior to TCP connect. The connection phase of
the SSH session is time-sensitive and often explicitly interactive.
The ultimate interactive/bulk TOS/DSCP will be set after
authentication completes.
* ssh(1), sshd(8): remove the pre-standardization cipher
rijnda...@lysator.liu.se. It is an alias for aes256-cbc before
it was standardized in RFC4253 (2006), has been deprecated and
disabled by default since OpenSSH 7.2 (2016) and was only briefly
documented in ssh.1 in 2001.
* ssh(1), sshd(8): update/replace the experimental post-quantum
hybrid key exchange method based on Streamlined NTRU Prime coupled
with X25519.
The previous sntrup4591761...@tinyssh.org method is
replaced with sntrup761x2...@openssh.com. Per its
designers, the sntrup4591761 algorithm was superseded almost two
years ago by sntrup761.
(note this both the updated method and the one that it replaced are
disabled by default)
* ssh(1): disable CheckHostIP by default. It provides insignificant
benefits while making key rotation significantly more difficult,
especially for hosts behind IP-based load-balancers.
Changes since OpenSSH 8.4
=========================
New features
------------
* ssh(1): this release enables UpdateHostkeys by default subject to
some conservative preconditions:
- The key was matched in the UserKnownHostsFile (and not in the
GlobalKnownHostsFile).
- The same key does not exist under another name.
- A certificate host key is not in use.
- known_hosts contains no matching wildcard hostname pattern.
- VerifyHostKeyDNS is not enabled.
We expect some of these conditions will be modified or relaxed in
future.
* ssh(1), sshd(8): add a new LogVerbose configuration directive for
that allows forcing maximum debug logging by file/function/line
pattern-lists.
* ssh(1): when prompting the user to accept a new hostkey, display
any other host names/addresses already associated with the key.
* ssh(1): allow UserKnownHostsFile=none to indicate that no
known_hosts file should be used to identify host keys.
* ssh(1): add a ssh_config KnownHostsCommand that allows the client
to obtain known_hosts data from a command in addition to the usual
files.
* ssh(1): for FIDO keys, if a signature operation fails with a
"incorrect PIN" reason and no PIN was initially requested from the
user, then request a PIN and retry the operation. This supports
some biometric devices that fall back to requiring PIN when reading
of the biometric failed, and devices that require PINs for all
hosted credentials.
* sshd(8): implement client address-based rate-limiting via new
sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize
directives that fine-grained control than the global MaxStartups
limit.
Bugfixes
--------
* ssh(1): Prefix keyboard interactive prompts with "(user@host)" to
make it easier to determine which connection they are associated
with in cases like scp -3, ProxyJump, etc. bz#3224
* sshd(8): fix sshd_config SetEnv directives located inside Match
blocks. GHPR#201
* ssh(1): when requesting a FIDO token touch on stderr, inform the
user once the touch has been recorded.
* ssh(1): prevent integer overflow when ridiculously large
ConnectTimeout values are specified, capping the effective value
(for most platforms) at 24 days. bz#3229
* ssh(1): consider the ECDSA key subtype when ordering host key
algorithms in the client,
* ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
that it control allowed key algorithms, when this option actually
specifies the signature algorithms that are accepted. The previous
name remains available as an alias. bz#3253
* ssh(1), sshd(8): similarly, rename HostbasedKeyTypes (ssh) and
HostbasedAcceptedKeyTypes (sshd) to HostbasedAcceptedAlgorithms.
* sftp-server(8): add missing lset...@openssh.com documentation
and advertisement in the server's SSH2_FXP_VERSION hello packet.
* ssh(1), sshd(8): more strictly enforce KEX state-machine by
banning packet types once they are received. Fixes memleak caused
by duplicate SSH2_MSG_KEX_DH_GEX_REQUEST (oss-fuzz #30078).
* sftp(1): allow the full range of UIDs/GIDs for chown/chgrp on 32bit
platforms instead of being limited by LONG_MAX. bz#3206
* Minor man page fixes (capitalization, commas, etc.) bz#3223
* sftp(1): when doing an sftp recursive upload or download of a
read-only directory, ensure that the directory is created with
write and execute permissions in the interim so that the transfer
can actually complete, then set the directory permission as the
final step. bz#3222
* ssh-keygen(1): document the -Z, check the validity of its argument
earlier and provide a better error message if it's not correct.
bz#2879
* ssh(1): ignore comments at the end of config lines in ssh_config,
similar to what we already do for sshd_config. bz#2320
* sshd_config(5): mention that DisableForwarding is valid in a
sshd_config Match block. bz3239
* sftp(1): fix incorrect sorting of "ls -ltr" under some
circumstances. bz3248.
* ssh(1), sshd(8): fix potential integer truncation of (unlikely)
timeout values. bz#3250
* ssh(1): make hostbased authentication send the signature algorithm
in its SSH2_MSG_USERAUTH_REQUEST packets instead of the key type.
This make HostbasedAcceptedAlgorithms do what it is supposed to -
filter on signature algorithm and not key type.
Portability
-----------
* sshd(8): add a number of platform-specific syscalls to the Linux
seccomp-bpf sandbox. bz#3232 bz#3260
* sshd(8): remove debug message from sigchld handler that could cause
deadlock on some platforms. bz#3259
* Sync contrib/ssh-copy-id with upstream.
* unittests: add a hostname function for systems that don't have it.
Some systems don't have a hostname command (it's not required by
POSIX). The do have uname -n (which is), but not all of those have
it report the FQDN.
OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de
Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre,
Tim Rice and Ben Lindstrom.
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Jakub Jelen
Feb 23, 2021, 3:44:08 PM2/23/21
to openssh-...@mindrot.org
On 2/23/21 2:46 AM, Damien Miller wrote:
> * ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
> PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
> that it control allowed key algorithms, when this option actually
> specifies the signature algorithms that are accepted. The previous
> name remains available as an alias. bz#3253
There is still one place in the manual page that refers to this meaning
> * ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
> PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
> that it control allowed key algorithms, when this option actually
> specifies the signature algorithms that are accepted. The previous
> name remains available as an alias. bz#3253
as key types in last snap:
commit c0a8a29c2487a2fcf83fdcd7a76cbdbe76fa7f73
Author: Jakub Jelen <jje...@redhat.com>
Date: Tue Feb 23 21:38:24 2021 +0100
sshd_config: Fix reference to algorithms as keys
diff --git a/sshd_config.5 b/sshd_config.5
index 108027b5..6376db10 100644
--- a/sshd_config.5
+++ b/sshd_config.5
@@ -1517,7 +1517,7 @@ sk-ecdsa-sh...@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa
.Ed
.Pp
-The list of available key types may also be obtained using
+The list of available signature algorithsm may also be obtained using
.Qq ssh -Q PubkeyAcceptedAlgorithms .
.It Cm PubkeyAuthOptions
Sets one or more public key authentication options.
Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
Jakub Jelen
Feb 23, 2021, 3:52:06 PM2/23/21
to openssh-...@mindrot.org
Obviously, the same is also in the ssh_config so attaching another
attempt also with a fixed typo in the previous.
commit a981cef1296d77ce70d371ba1fe3d4e5b64ee79d
Author: Jakub Jelen <jje...@redhat.com>
Date: Tue Feb 23 21:38:24 2021 +0100
sshd_config: Fix reference to algorithms as keys
diff --git a/ssh_config.5 b/ssh_config.5
index 1a36427d..73401583 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -1422,7 +1422,7 @@ sk-ecdsa-sh...@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa
.Ed
.Pp
-The list of available key types may also be obtained using
+The list of available signature algorithms types may also be obtained using
.Qq ssh -Q PubkeyAcceptedAlgorithms .
.It Cm PubkeyAuthentication
Specifies whether to try public key authentication.
diff --git a/sshd_config.5 b/sshd_config.5
index 108027b5..8deb162d 100644
--- a/sshd_config.5
+++ b/sshd_config.5
@@ -1517,7 +1517,7 @@ sk-ecdsa-sh...@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa
.Ed
.Pp
-The list of available key types may also be obtained using
+The list of available signature algorithms may also be obtained using
Damien Miller
Feb 23, 2021, 4:58:18 PM2/23/21
to Jakub Jelen, openssh-...@mindrot.org
Thanks - I have fixed these and a few more that were lurking under
HostbasedAcceptedAlgorithms and HostKeyAlgorithms.
-d
Phil Pennock
Feb 23, 2021, 7:11:00 PM2/23/21
to openssh-...@mindrot.org
On 2021-02-23 at 12:46 +1100, Damien Miller wrote:
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
Ubuntu 20.04/amd64: all tests passed [openssh-SNAP-20210224.tar.gz]
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
> * ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
> PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
> that it control allowed key algorithms, when this option actually
> specifies the signature algorithms that are accepted. The previous
> name remains available as an alias. bz#3253
me to test it out.
Not a regression but an existing issue (seen in 8.3p1), unknown if bug
or comprehension issue but reporting now to fix either docs or code
before release:
# /etc/ssh/sshd_config:
PubkeyAcceptedAlgorithms -ssh-rsa,-ssh-rsa-cert-*,-rsa*
# command-line:
sshd -T | grep -i '^PubkeyAcceptedKeyTypes'
pubkeyacceptedkeytypes ssh-ed2551...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-n...@openssh.com,rsa-sha2-5...@openssh.com,rsa-sha2-2...@openssh.com,ssh-rsa-...@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-...@openssh.com,sk-ecdsa-sh...@openssh.com,rsa-sha2-512,rsa-sha2-256
So besides the option not being renamed or duplicated under both names
for compatibility ... the glob removals don't work, and attempts to
remove rsa-sha2-256 explicitly don't work here either. Something seems
to be adding them back in?
-Phil
Darren Tucker
Feb 23, 2021, 8:13:18 PM2/23/21
to Phil Pennock, openssh-...@mindrot.org
On Tue, Feb 23, 2021 at 07:08:05PM -0500, Phil Pennock wrote:
[...]
oversight on my part (the old names are still listed first, so the
config dumper finds them ahead of the new names).
diff --git a/readconf.c b/readconf.c
index b0a85097..a05be047 100644
--- a/readconf.c
+++ b/readconf.c
@@ -308,10 +308,10 @@ static struct {
{ "revokedhostkeys", oRevokedHostKeys },
{ "fingerprinthash", oFingerprintHash },
{ "updatehostkeys", oUpdateHostkeys },
- { "hostbasedkeytypes", oHostbasedAcceptedAlgorithms }, /* obsolete */
{ "hostbasedalgorithms", oHostbasedAcceptedAlgorithms },
- { "pubkeyacceptedkeytypes", oPubkeyAcceptedAlgorithms }, /* obsolete */
+ { "hostbasedkeytypes", oHostbasedAcceptedAlgorithms }, /* obsolete */
{ "pubkeyacceptedalgorithms", oPubkeyAcceptedAlgorithms },
+ { "pubkeyacceptedkeytypes", oPubkeyAcceptedAlgorithms }, /* obsolete */
{ "ignoreunknown", oIgnoreUnknown },
{ "proxyjump", oProxyJump },
{ "securitykeyprovider", oSecurityKeyProvider },
diff --git a/servconf.c b/servconf.c
index b782ccbb..7e94d2d7 100644
--- a/servconf.c
+++ b/servconf.c
@@ -559,13 +559,13 @@ static struct {
{ "rhostsrsaauthentication", sDeprecated, SSHCFG_ALL },
{ "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_ALL },
{ "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, SSHCFG_ALL },
- { "hostbasedacceptedkeytypes", sHostbasedAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "hostbasedacceptedalgorithms", sHostbasedAcceptedAlgorithms, SSHCFG_ALL },
+ { "hostbasedacceptedkeytypes", sHostbasedAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "hostkeyalgorithms", sHostKeyAlgorithms, SSHCFG_GLOBAL },
{ "rsaauthentication", sDeprecated, SSHCFG_ALL },
{ "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_ALL },
- { "pubkeyacceptedkeytypes", sPubkeyAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "pubkeyacceptedalgorithms", sPubkeyAcceptedAlgorithms, SSHCFG_ALL },
+ { "pubkeyacceptedkeytypes", sPubkeyAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "pubkeyauthoptions", sPubkeyAuthOptions, SSHCFG_ALL },
{ "dsaauthentication", sPubkeyAuthentication, SSHCFG_GLOBAL }, /* alias */
#ifdef KRB5
--
Darren Tucker (dtucker at dtucker.net)
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.
[...]
> # command-line:
> sshd -T | grep -i '^PubkeyAcceptedKeyTypes'
>
> pubkeyacceptedkeytypes [...]
> sshd -T | grep -i '^PubkeyAcceptedKeyTypes'
>
>
> So besides the option not being renamed or duplicated
They should not be duplicated, but the not being renamed is an
> So besides the option not being renamed or duplicated
oversight on my part (the old names are still listed first, so the
config dumper finds them ahead of the new names).
diff --git a/readconf.c b/readconf.c
index b0a85097..a05be047 100644
--- a/readconf.c
+++ b/readconf.c
@@ -308,10 +308,10 @@ static struct {
{ "revokedhostkeys", oRevokedHostKeys },
{ "fingerprinthash", oFingerprintHash },
{ "updatehostkeys", oUpdateHostkeys },
- { "hostbasedkeytypes", oHostbasedAcceptedAlgorithms }, /* obsolete */
{ "hostbasedalgorithms", oHostbasedAcceptedAlgorithms },
- { "pubkeyacceptedkeytypes", oPubkeyAcceptedAlgorithms }, /* obsolete */
+ { "hostbasedkeytypes", oHostbasedAcceptedAlgorithms }, /* obsolete */
{ "pubkeyacceptedalgorithms", oPubkeyAcceptedAlgorithms },
+ { "pubkeyacceptedkeytypes", oPubkeyAcceptedAlgorithms }, /* obsolete */
{ "ignoreunknown", oIgnoreUnknown },
{ "proxyjump", oProxyJump },
{ "securitykeyprovider", oSecurityKeyProvider },
diff --git a/servconf.c b/servconf.c
index b782ccbb..7e94d2d7 100644
--- a/servconf.c
+++ b/servconf.c
@@ -559,13 +559,13 @@ static struct {
{ "rhostsrsaauthentication", sDeprecated, SSHCFG_ALL },
{ "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_ALL },
{ "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, SSHCFG_ALL },
- { "hostbasedacceptedkeytypes", sHostbasedAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "hostbasedacceptedalgorithms", sHostbasedAcceptedAlgorithms, SSHCFG_ALL },
+ { "hostbasedacceptedkeytypes", sHostbasedAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "hostkeyalgorithms", sHostKeyAlgorithms, SSHCFG_GLOBAL },
{ "rsaauthentication", sDeprecated, SSHCFG_ALL },
{ "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_ALL },
- { "pubkeyacceptedkeytypes", sPubkeyAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "pubkeyacceptedalgorithms", sPubkeyAcceptedAlgorithms, SSHCFG_ALL },
+ { "pubkeyacceptedkeytypes", sPubkeyAcceptedAlgorithms, SSHCFG_ALL }, /* obsolete */
{ "pubkeyauthoptions", sPubkeyAuthOptions, SSHCFG_ALL },
{ "dsaauthentication", sPubkeyAuthentication, SSHCFG_GLOBAL }, /* alias */
#ifdef KRB5
--
Darren Tucker (dtucker at dtucker.net)
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.
Darren Tucker
Feb 24, 2021, 8:54:56 AM2/24/21
to Phil Pennock, OpenSSH Devel List
On Wed, 24 Feb 2021 at 11:16, Phil Pennock <phil.p...@globnix.org> wrote:
> # /etc/ssh/sshd_config:
> PubkeyAcceptedAlgorithms -ssh-rsa,-ssh-rsa-cert-*,-rsa*
"If the specified list begins with a '-' character, then the
specified key types (including wildcards)will be removed from the
default set instead of replacing them."
Only the first "-" indicates the specified patterns are to be removed,
the other ones form part of the patterns and thus don't match any
algorithms. You probably want something like:
$ sudo ./sshd -T -o 'PubkeyAcceptedAlgorithms
-ssh-rsa,ssh-rsa-cert-*,rsa*' | grep -i PubkeyAcceptedAlgorithms
pubkeyacceptedalgorithms
ssh-ed2551...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-n...@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-...@openssh.com,sk-ecdsa-sh...@openssh.com
--
Darren Tucker (dtucker at dtucker.net)
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.
> # /etc/ssh/sshd_config:
> PubkeyAcceptedAlgorithms -ssh-rsa,-ssh-rsa-cert-*,-rsa*
"If the specified list begins with a '-' character, then the
specified key types (including wildcards)will be removed from the
default set instead of replacing them."
Only the first "-" indicates the specified patterns are to be removed,
the other ones form part of the patterns and thus don't match any
algorithms. You probably want something like:
$ sudo ./sshd -T -o 'PubkeyAcceptedAlgorithms
-ssh-rsa,ssh-rsa-cert-*,rsa*' | grep -i PubkeyAcceptedAlgorithms
pubkeyacceptedalgorithms
ssh-ed2551...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-n...@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-...@openssh.com,sk-ecdsa-sh...@openssh.com
--
Darren Tucker (dtucker at dtucker.net)
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.
Phil Pennock
Feb 24, 2021, 11:23:11 AM2/24/21
to Darren Tucker, OpenSSH Devel List
On 2021-02-25 at 00:51 +1100, Darren Tucker wrote:
> "If the specified list begins with a '-' character, then the
> specified key types (including wildcards)will be removed from the
> default set instead of replacing them."
So, comprehension issue, I was being illiterate. Thank you, sorry for
> "If the specified list begins with a '-' character, then the
> specified key types (including wildcards)will be removed from the
> default set instead of replacing them."
that bit of noise.
-Phil, consoling himself that at least one real issue got fixed
Jakub Jelen
Feb 25, 2021, 3:55:23 AM2/25/21
to openssh-...@mindrot.org, Philip Hands
On 2/23/21 2:46 AM, Damien Miller wrote:
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
could you also update the ssh-copy-id from Phil?
https://gitlab.com/phil_hands/ssh-copy-id
There were couple of commits since the last update that would be helpful
to bring in.
Added Phil to CC just to make sure there are no other things that he
would like to merge before. There are just couple of issues related to
the usage of the -s switch now.
Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
Darren Tucker
Feb 25, 2021, 9:13:57 AM2/25/21
to Jakub Jelen, OpenSSH Devel List, Philip Hands
On Thu, 25 Feb 2021 at 20:00, Jakub Jelen <jje...@redhat.com> wrote:
> Hi,
> could you also update the ssh-copy-id from Phil?
I just pulled in all of the changes from Phil's tree as of right now.
> Hi,
> could you also update the ssh-copy-id from Phil?
Please let me know if there are any other last minute additions that
should go in before the release.
--
Darren Tucker (dtucker at dtucker.net)
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.
Dmitry Belyavskiy
Feb 25, 2021, 9:22:47 AM2/25/21
to Darren Tucker, Jakub Jelen, OpenSSH Devel List
Dear Darren,
If the proposed Edwards solution (
https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd
like to clean it up and get it added.
--
Dmitry Belyavskiy
If the proposed Edwards solution (
https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd
like to clean it up and get it added.
Dmitry Belyavskiy
Darren Tucker
Feb 25, 2021, 9:45:46 AM2/25/21
to Dmitry Belyavskiy, Jakub Jelen, OpenSSH Devel List
On Fri, 26 Feb 2021 at 01:21, Dmitry Belyavskiy <dbel...@redhat.com> wrote:
> If the proposed Edwards solution (https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd like to clean it up and get it added.
I'll defer to Damien but to me that looks too big to go in this late
in the release cycle.
> If the proposed Edwards solution (https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd like to clean it up and get it added.
I'll defer to Damien but to me that looks too big to go in this late
in the release cycle.
Jakub Jelen
Feb 25, 2021, 9:52:31 AM2/25/21
to openssh-...@mindrot.org
On 2/25/21 3:11 PM, Darren Tucker wrote:
> On Thu, 25 Feb 2021 at 20:00, Jakub Jelen <jje...@redhat.com> wrote:
>> Hi,
>> could you also update the ssh-copy-id from Phil?
>
> I just pulled in all of the changes from Phil's tree as of right now.
> Please let me know if there are any other last minute additions that
> should go in before the release.
Thank you.
> On Thu, 25 Feb 2021 at 20:00, Jakub Jelen <jje...@redhat.com> wrote:
>> Hi,
>> could you also update the ssh-copy-id from Phil?
>
> I just pulled in all of the changes from Phil's tree as of right now.
> Please let me know if there are any other last minute additions that
> should go in before the release.
Now, I have all the test results (from the first snap) with our patches
and I did not notice any unexpected failures.
Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
Damien Miller
Feb 25, 2021, 5:19:28 PM2/25/21
to Darren Tucker, Dmitry Belyavskiy, Jakub Jelen, OpenSSH Devel List
On Fri, 26 Feb 2021, Darren Tucker wrote:
> On Fri, 26 Feb 2021 at 01:21, Dmitry Belyavskiy <dbel...@redhat.com> wrote:
> > If the proposed Edwards solution (https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd like to clean it up and get it added.
>
> I'll defer to Damien but to me that looks too big to go in this late
> in the release cycle.
yes, it's too late in the cycle for this. We also don't have any
> On Fri, 26 Feb 2021 at 01:21, Dmitry Belyavskiy <dbel...@redhat.com> wrote:
> > If the proposed Edwards solution (https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd like to clean it up and get it added.
>
> I'll defer to Damien but to me that looks too big to go in this late
> in the release cycle.
hardware to test it against - experience has made me reticent to ship
anything to do with PKCS#11 that we can test against only a single
software implementation.
A bigger problem however is libcrypto compatibility. The last time I
checked, libressl lacks the EVP_PKEY functionality for ED25519 keys.
They were considering it then, but I'll have to check back and see
what the status is.
-d
Corinna Vinschen
Feb 25, 2021, 5:36:47 PM2/25/21
to openssh-...@mindrot.org
On Feb 23 12:46, Damien Miller wrote:
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
Builds OOTB on Cygwin, all tests pass.
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
Thanks,
Corinna
Volker Diels-Grabsch
Feb 25, 2021, 7:59:36 PM2/25/21
to openssh-...@mindrot.org
Dear Damien,
Is it still possible to include the ssh_config improvements which I proposed last Sunday on this mailing list?
For your convenience, I also created a pull request:
https://github.com/openssh/openssh-portable/pull/231
Best regards,
Volker
--
Volker Diels-Grabsch
----<<<((()))>>>----
Is it still possible to include the ssh_config improvements which I proposed last Sunday on this mailing list?
For your convenience, I also created a pull request:
https://github.com/openssh/openssh-portable/pull/231
Best regards,
Volker
Volker Diels-Grabsch
----<<<((()))>>>----
Damien Miller
Feb 25, 2021, 9:07:57 PM2/25/21
to Volker Diels-Grabsch, openssh-...@mindrot.org
On Fri, 26 Feb 2021, Volker Diels-Grabsch wrote:
> Dear Damien,
>
> Is it still possible to include the ssh_config improvements which I
> proposed last Sunday on this mailing list?
No sorry, but I'll look at the right after release. We'll be doing
> Dear Damien,
>
> Is it still possible to include the ssh_config improvements which I
> proposed last Sunday on this mailing list?
another release in 2-3 months, so not long to wait.
-d
Hisashi T Fujinaka
Feb 25, 2021, 10:22:31 PM2/25/21
to Damien Miller, openssh-...@mindrot.org
In NetBSD-current, I get the following:
ok known hosts command
all t-exec passed
BUILDDIR=`pwd`; cd ./regress || exit $?; EGREP='/usr/bin/grep -E' make .OBJDIR="${BUILDDIR}/regress" .CURDIR="`pwd`" BUILDDIR="${BUILDDIR}" OBJ="${BUILDDIR}/regress/" PATH="${BUILDDIR}:${PATH}" TEST_ENV=MALLOC_OPTIONS="AJRX" TEST_MALLOC_OPTIONS="AJRX" TEST_SSH_SCP="${BUILDDIR}/scp" TEST_SSH_SSH="${BUILDDIR}/ssh" TEST_SSH_SSHD="${BUILDDIR}/sshd" TEST_SSH_SSHAGENT="${BUILDDIR}/ssh-agent" TEST_SSH_SSHADD="${BUILDDIR}/ssh-add" TEST_SSH_SSHKEYGEN="${BUILDDIR}/ssh-keygen" TEST_SSH_SSHPKCS11HELPER="${BUILDDIR}/ssh-pkcs11-helper" TEST_SSH_SSHKEYSCAN="${BUILDDIR}/ssh-keyscan" TEST_SSH_SFTP="${BUILDDIR}/sftp" TEST_SSH_PKCS11_HELPER="${BUILDDIR}/ssh-pkcs11-helper" TEST_SSH_SK_HELPER="${BUILDDIR}/ssh-sk-helper" TEST_SSH_SFTPSERVER="${BUILDDIR}/sftp-server" TEST_SSH_PLINK="plink" TEST_SSH_PUTTYGEN="puttygen" TEST_SSH_CONCH="conch" TEST_SSH_IPV6="yes" TEST_SSH_UTF8="yes" TEST_SSH_ECC="yes" TEST_SHELL="sh" EXEEXT="" interop-tests && echo all interop-tests pas!
sed
run test putty-transfer.sh ...
putty interop tests not enabled
run test putty-ciphers.sh ...
putty interop tests not enabled
run test putty-kex.sh ...
putty interop tests not enabled
run test conch-ciphers.sh ...
conch interop tests not enabled
all interop-tests passed
cc -o regress/misc/kexfuzz/kexfuzz -L. -Lopenbsd-compat/ -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong regress/misc/kexfuzz/kexfuzz.o ssh-sk-client.o -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypt -lcrypto -lutil -lz
ld: regress/misc/kexfuzz/kexfuzz.o: in function `do_send_and_receive':
/home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:117: undefined reference to `debug'
ld: /home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:121: undefined reference to `debug'
ld: regress/misc/kexfuzz/kexfuzz.o: in function `run_kex':
/home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:181: undefined reference to `debug'
ld: /home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:185: undefined reference to `debug'
*** Error code 1
Stop.
make: stopped in /home/htodd/git/openssh
--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
ok known hosts command
all t-exec passed
BUILDDIR=`pwd`; cd ./regress || exit $?; EGREP='/usr/bin/grep -E' make .OBJDIR="${BUILDDIR}/regress" .CURDIR="`pwd`" BUILDDIR="${BUILDDIR}" OBJ="${BUILDDIR}/regress/" PATH="${BUILDDIR}:${PATH}" TEST_ENV=MALLOC_OPTIONS="AJRX" TEST_MALLOC_OPTIONS="AJRX" TEST_SSH_SCP="${BUILDDIR}/scp" TEST_SSH_SSH="${BUILDDIR}/ssh" TEST_SSH_SSHD="${BUILDDIR}/sshd" TEST_SSH_SSHAGENT="${BUILDDIR}/ssh-agent" TEST_SSH_SSHADD="${BUILDDIR}/ssh-add" TEST_SSH_SSHKEYGEN="${BUILDDIR}/ssh-keygen" TEST_SSH_SSHPKCS11HELPER="${BUILDDIR}/ssh-pkcs11-helper" TEST_SSH_SSHKEYSCAN="${BUILDDIR}/ssh-keyscan" TEST_SSH_SFTP="${BUILDDIR}/sftp" TEST_SSH_PKCS11_HELPER="${BUILDDIR}/ssh-pkcs11-helper" TEST_SSH_SK_HELPER="${BUILDDIR}/ssh-sk-helper" TEST_SSH_SFTPSERVER="${BUILDDIR}/sftp-server" TEST_SSH_PLINK="plink" TEST_SSH_PUTTYGEN="puttygen" TEST_SSH_CONCH="conch" TEST_SSH_IPV6="yes" TEST_SSH_UTF8="yes" TEST_SSH_ECC="yes" TEST_SHELL="sh" EXEEXT="" interop-tests && echo all interop-tests pas!
sed
run test putty-transfer.sh ...
putty interop tests not enabled
run test putty-ciphers.sh ...
putty interop tests not enabled
run test putty-kex.sh ...
putty interop tests not enabled
run test conch-ciphers.sh ...
conch interop tests not enabled
all interop-tests passed
cc -o regress/misc/kexfuzz/kexfuzz -L. -Lopenbsd-compat/ -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong regress/misc/kexfuzz/kexfuzz.o ssh-sk-client.o -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lcrypt -lcrypto -lutil -lz
ld: regress/misc/kexfuzz/kexfuzz.o: in function `do_send_and_receive':
/home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:117: undefined reference to `debug'
ld: /home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:121: undefined reference to `debug'
ld: regress/misc/kexfuzz/kexfuzz.o: in function `run_kex':
/home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:181: undefined reference to `debug'
ld: /home/htodd/openssh/regress/misc/kexfuzz/kexfuzz.c:185: undefined reference to `debug'
*** Error code 1
Stop.
make: stopped in /home/htodd/git/openssh
--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Damien Miller
Feb 25, 2021, 11:18:27 PM2/25/21
to Hisashi T Fujinaka, openssh-...@mindrot.org
Thanks I think I might remove regress/misc/kexfuzz entirely, it has
been obsoleted by regress/misc/fuzz_harness/kex_fuzz.cc :)
been obsoleted by regress/misc/fuzz_harness/kex_fuzz.cc :)
Dmitry Belyavskiy
Feb 26, 2021, 3:22:09 AM2/26/21
to Damien Miller, Darren Tucker, Jakub Jelen, OpenSSH Devel List
Dear Damien
On Thu, Feb 25, 2021 at 11:17 PM Damien Miller <d...@mindrot.org> wrote:
> On Fri, 26 Feb 2021, Darren Tucker wrote:
>
> > On Fri, 26 Feb 2021 at 01:21, Dmitry Belyavskiy <dbel...@redhat.com>
> wrote:
> > > If the proposed Edwards solution (
> https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd
> like to clean it up and get it added.
> >
> > I'll defer to Damien but to me that looks too big to go in this late
> > in the release cycle.
>
> yes, it's too late in the cycle for this.
Pity but understandable.
> We also don't have any
> hardware to test it against - experience has made me reticent to ship
> anything to do with PKCS#11 that we can test against only a single
> software implementation.
>
Even more pity, but even more understandable.
>
> A bigger problem however is libcrypto compatibility. The last time I
> checked, libressl lacks the EVP_PKEY functionality for ED25519 keys.
> They were considering it then, but I'll have to check back and see
> what the status is.
>
I've added linking-time detection for the EVP_PKEY functionality for
ED25519 keys.
We will not be able to work with keys from X509 certificates but it seems
the only limitation.
Many thanks anyway!
--
Dmitry Belyavskiy
On Thu, Feb 25, 2021 at 11:17 PM Damien Miller <d...@mindrot.org> wrote:
> On Fri, 26 Feb 2021, Darren Tucker wrote:
>
> > On Fri, 26 Feb 2021 at 01:21, Dmitry Belyavskiy <dbel...@redhat.com>
> wrote:
> > > If the proposed Edwards solution (
> https://github.com/openssh/openssh-portable/pull/230) is not too big, I'd
> like to clean it up and get it added.
> >
> > I'll defer to Damien but to me that looks too big to go in this late
> > in the release cycle.
>
> yes, it's too late in the cycle for this.
> We also don't have any
> hardware to test it against - experience has made me reticent to ship
> anything to do with PKCS#11 that we can test against only a single
> software implementation.
>
>
> A bigger problem however is libcrypto compatibility. The last time I
> checked, libressl lacks the EVP_PKEY functionality for ED25519 keys.
> They were considering it then, but I'll have to check back and see
> what the status is.
>
ED25519 keys.
We will not be able to work with keys from X509 certificates but it seems
the only limitation.
Many thanks anyway!
--
Dmitry Belyavskiy
Jeff Wieland
Feb 27, 2021, 2:27:47 PM2/27/21
to Damien Miller, openssh-...@mindrot.org
Damien Miller wrote:
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
>
>
Builds as 32 bit on SPARC Solaris 10, using Studio 12.2 and our local build
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
>
>
of OpenSSL 1.1.1j, and passes all tests.
--
Jeff Wieland, UNIX Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms
Morgan, Iain (ARC-TN)[InuTeq, LLC]
Feb 27, 2021, 6:02:47 PM2/27/21
to Damien Miller, openssh-...@mindrot.org
On 2/22/21, 17:56, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+imorgan=nas.na...@mindrot.org on behalf of d...@mindrot.org> wrote:
Hi,
OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a bugfix release.
...
Hi,
OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a bugfix release.
* sshd(8): implement client address-based rate-limiting via new
sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize
directives that fine-grained control than the global MaxStartups
limit.
--
Iain Morgan
Damien Miller
Feb 27, 2021, 7:33:13 PM2/27/21
to Morgan, Iain (ARC-TN)[InuTeq, LLC], openssh-...@mindrot.org
fixed - thanks
raf
Feb 27, 2021, 7:53:50 PM2/27/21
to openssh-...@mindrot.org
On Sat, Feb 27, 2021 at 10:58:52PM +0000, "Morgan, Iain (ARC-TN)[InuTeq, LLC]" <iain....@nasa.gov> wrote:
> On 2/22/21, 17:56, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+imorgan=nas.na...@mindrot.org on behalf of d...@mindrot.org> wrote:
>
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
>
> ...
>
> * sshd(8): implement client address-based rate-limiting via new
> sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize
> directives that fine-grained control than the global MaxStartups
> limit.
>
>
> The sshd_config(5) man page has these new options listed after PidFile, whereas they should be listed before.
>
> --
> Iain Morgan
Also, the grammar seems wrong: "directives that
> On 2/22/21, 17:56, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+imorgan=nas.na...@mindrot.org on behalf of d...@mindrot.org> wrote:
>
> Hi,
>
> OpenSSH 8.5p1 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a bugfix release.
>
> ...
>
> * sshd(8): implement client address-based rate-limiting via new
> sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize
> directives that fine-grained control than the global MaxStartups
> limit.
>
>
> The sshd_config(5) man page has these new options listed after PidFile, whereas they should be listed before.
>
> --
> Iain Morgan
fine-grained control than" should probably be
"directives that provide more fine-grained control
than" (if this is a quote from the manpage and not
just a changelog).
cheers,
raf
Damien Miller
Feb 28, 2021, 11:56:59 PM2/28/21
to raf, openssh-...@mindrot.org
On Sun, 28 Feb 2021, raf wrote:
> Also, the grammar seems wrong: "directives that
> fine-grained control than" should probably be
> "directives that provide more fine-grained control
> than" (if this is a quote from the manpage and not
> just a changelog).
It's just the release notes, but I still appreciate the feedback so
> Also, the grammar seems wrong: "directives that
> fine-grained control than" should probably be
> "directives that provide more fine-grained control
> than" (if this is a quote from the manpage and not
> just a changelog).
the final version will be less wrong :)
-d
Volker Diels-Grabsch
Mar 25, 2021, 5:18:15 AM3/25/21
to Damien Miller, openssh-...@mindrot.org
Dear Damien,
Damien Miller wrote:
> On Fri, 26 Feb 2021, Volker Diels-Grabsch wrote:
>
> > Is it still possible to include the ssh_config improvements which I
> > proposed last Sunday on this mailing list?
>
> No sorry, but I'll look at the right after release. We'll be doing
> another release in 2-3 months, so not long to wait.
Did you meanwhile find some time to have a look at this?
FYI, I rebased the patches to the latest master and ensured that they
still apply and compile correctly:
Damien Miller wrote:
> On Fri, 26 Feb 2021, Volker Diels-Grabsch wrote:
>
> > Is it still possible to include the ssh_config improvements which I
> > proposed last Sunday on this mailing list?
>
> No sorry, but I'll look at the right after release. We'll be doing
> another release in 2-3 months, so not long to wait.
FYI, I rebased the patches to the latest master and ensured that they
still apply and compile correctly:
--
Volker Diels-Grabsch
----<<<((()))>>>----
Volker Diels-Grabsch
----<<<((()))>>>----
Volker Diels-Grabsch
May 4, 2021, 5:03:49 AM5/4/21
to Damien Miller, openssh-...@mindrot.org
Dear Damien,
Damien Miller wrote:
Damien Miller wrote:
> On Fri, 26 Feb 2021, Volker Diels-Grabsch wrote:
> >
> > Is it still possible to include the ssh_config improvements which I
> > proposed last Sunday on this mailing list?
>
> No sorry, but I'll look at the right after release. We'll be doing
> another release in 2-3 months, so not long to wait.
Meanwhile, that version (8.6) was released as well.
> >
> > Is it still possible to include the ssh_config improvements which I
> > proposed last Sunday on this mailing list?
>
> No sorry, but I'll look at the right after release. We'll be doing
> another release in 2-3 months, so not long to wait.
Is there any chance to include this handy patch in the release thereafter (8.7)?
For your convenience: https://github.com/openssh/openssh-portable/pull/231
Best regards,
Volker
--
Volker Diels-Grabsch
----<<<((()))>>>----
Damien Miller
May 4, 2021, 6:43:21 PM5/4/21
to Volker Diels-Grabsch, openssh-...@mindrot.org
On Tue, 4 May 2021, Volker Diels-Grabsch wrote:
> Dear Damien,
>
> Damien Miller wrote:
> > On Fri, 26 Feb 2021, Volker Diels-Grabsch wrote:
> > >
> > > Is it still possible to include the ssh_config improvements which I
> > > proposed last Sunday on this mailing list?
> >
> > No sorry, but I'll look at the right after release. We'll be doing
> > another release in 2-3 months, so not long to wait.
>
> Meanwhile, that version (8.6) was released as well.
>
> Is there any chance to include this handy patch in the release thereafter (8.7)?
>
> For your convenience: https://github.com/openssh/openssh-portable/pull/231
Sorry - have been very busy with the day job but will start catching up on
> Dear Damien,
>
> Damien Miller wrote:
> > On Fri, 26 Feb 2021, Volker Diels-Grabsch wrote:
> > >
> > > Is it still possible to include the ssh_config improvements which I
> > > proposed last Sunday on this mailing list?
> >
> > No sorry, but I'll look at the right after release. We'll be doing
> > another release in 2-3 months, so not long to wait.
>
> Meanwhile, that version (8.6) was released as well.
>
> Is there any chance to include this handy patch in the release thereafter (8.7)?
>
> For your convenience: https://github.com/openssh/openssh-portable/pull/231
patch requests soon.
-d
Volker Diels-Grabsch
Jun 3, 2021, 12:34:13 PM6/3/21
to Damien Miller, openssh-...@mindrot.org
Ping.
[ If there's anything I can do to reduce the barrier, such as posting
the pull request as patch files to the mailing list, or anything,
please let me know. ]
Best regards,
Volker
Damien Miller wrote:
[ If there's anything I can do to reduce the barrier, such as posting
the pull request as patch files to the mailing list, or anything,
please let me know. ]
Best regards,
Volker
Damien Miller wrote:
--
Volker Diels-Grabsch
----<<<((()))>>>----
Volker Diels-Grabsch
----<<<((()))>>>----
Damien Miller
Jun 8, 2021, 3:26:53 AM6/8/21
to Volker Diels-Grabsch, openssh-...@mindrot.org
On Thu, 3 Jun 2021, Volker Diels-Grabsch wrote:
> Ping.
>
> [ If there's anything I can do to reduce the barrier, such as posting
> the pull request as patch files to the mailing list, or anything,
> please let me know. ]
Looking at these now.
> Ping.
>
> [ If there's anything I can do to reduce the barrier, such as posting
> the pull request as patch files to the mailing list, or anything,
> please let me know. ]
I'm not sure about the naming of NoShell, because it's really about not
starting any kind of remote session. E.g. the existing -N talks about
not executing a remote command. Talking about shells I think runs the
risk that people will assume it somehow skips the remote shell for
command execution. They would probably find out soon enough that they
were wrong, but IMO it's better to avoid it altogether.
So the options are to rename the option to something like NoSession,
find a way to reuse the existing RemoteCommand option (though that is
IMO a little ugly) or perhaps introduce a new "SessionType" option
that can subsume functionality of both the -N (SessionType=none) and
-s (SessionType=subsystem) flags.
What do you think?
Volker Diels-Grabsch
Jun 8, 2021, 6:39:19 AM6/8/21
to Damien Miller, openssh-...@mindrot.org
Dear Damien,
Thanks for your response!
Damien Miller wrote:
> I'm not sure about the naming of NoShell, because it's really about not
> starting any kind of remote session.
I didn't really care about how to name this. All I did was noting
that the flag is stored in a C variable "no_shell", which I just
translated to camel case.
So I assume that we should rename that C variable as well?
> So the options are to rename the option to something like NoSession,
> find a way to reuse the existing RemoteCommand option (though that is
> IMO a little ugly) or perhaps introduce a new "SessionType" option
> that can subsume functionality of both the -N (SessionType=none) and
> -s (SessionType=subsystem) flags.
>
> What do you think?
I also don't think that reusing RemoteCommand is a good idea. This
would add unnecessary entaglement of mostly-unrelated options, and as
such increase the risk of accidentally introducing bugs.
I'd prefer to rename NoShell to NoSession, and perhaps to do the same
for the internal variable names for consistency. Then, we would have
a one-to-one match of command line and configuration file, which is
IMHO the least surprise for users already familiar with "-N" and "-s".
However, I'm not opposed to introduce "SessionType=none/subsystem", in
case you like me to implement it that way.
How should we proceed from here? Which variant should I implement?
Best regards,
Volker
--
Volker Diels-Grabsch
----<<<((()))>>>----
Thanks for your response!
Damien Miller wrote:
> I'm not sure about the naming of NoShell, because it's really about not
> starting any kind of remote session.
that the flag is stored in a C variable "no_shell", which I just
translated to camel case.
So I assume that we should rename that C variable as well?
> So the options are to rename the option to something like NoSession,
> find a way to reuse the existing RemoteCommand option (though that is
> IMO a little ugly) or perhaps introduce a new "SessionType" option
> that can subsume functionality of both the -N (SessionType=none) and
> -s (SessionType=subsystem) flags.
>
> What do you think?
would add unnecessary entaglement of mostly-unrelated options, and as
such increase the risk of accidentally introducing bugs.
I'd prefer to rename NoShell to NoSession, and perhaps to do the same
for the internal variable names for consistency. Then, we would have
a one-to-one match of command line and configuration file, which is
IMHO the least surprise for users already familiar with "-N" and "-s".
However, I'm not opposed to introduce "SessionType=none/subsystem", in
case you like me to implement it that way.
How should we proceed from here? Which variant should I implement?
Best regards,
Volker
--
Volker Diels-Grabsch
----<<<((()))>>>----
Morgan, Iain (ARC-TN)[InuTeq, LLC]
Jun 8, 2021, 2:13:05 PM6/8/21
to Volker Diels-Grabsch, Damien Miller, openssh-...@mindrot.org
Hi,
Of the choices enumerated by Damien, SessionType seems the most useful. I assume there should be a third value to designate a normal interactive session. Although, I'm dubious about the ovbious choice of "interactive."
--
Iain Morgan
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev&data=04%7C01%7Ciain.morgan%40nasa.gov%7C633c1ca29ea34f159b1a08d92a695976%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637587454241342637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SDC3Kxmia3vcxRyfpm%2FTAbH3vCj4EdctwTyUb5oR6FU%3D&reserved=0
Of the choices enumerated by Damien, SessionType seems the most useful. I assume there should be a third value to designate a normal interactive session. Although, I'm dubious about the ovbious choice of "interactive."
--
Iain Morgan
Damien Miller
Jun 8, 2021, 6:17:57 PM6/8/21
to Morgan, Iain (ARC-TN)[InuTeq, LLC], Volker Diels-Grabsch, openssh-...@mindrot.org
On Tue, 8 Jun 2021, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
> Hi,
>
> Of the choices enumerated by Damien, SessionType seems the most
> useful. I assume there should be a third value to designate a normal
> interactive session. Although, I'm dubious about the ovbious choice of
> "interactive."
I was thinking "default" - not very imaginative, I know...
> Hi,
>
> Of the choices enumerated by Damien, SessionType seems the most
> useful. I assume there should be a third value to designate a normal
> interactive session. Although, I'm dubious about the ovbious choice of
> "interactive."
-d
Morgan, Iain (ARC-TN)[InuTeq, LLC]
Jun 8, 2021, 6:42:46 PM6/8/21
to Damien Miller, Volker Diels-Grabsch, openssh-...@mindrot.org
Yeah, I had considered "default" as well. I was hoping for something more descriptive and more in keeping with the general style of option values. But, I don't have any better suggestion.
--
Iain Morgan
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev&data=04%7C01%7Ciain.morgan%40nasa.gov%7Cbd2a377dbe7249592dca08d92acafaac%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637587873548173397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QFP8h1NV0sVu6OS0BSpid0pjhuA0fCbDa9Haou80Gw0%3D&reserved=0
--
Iain Morgan
Jochen Bern
Jun 9, 2021, 5:58:04 AM6/9/21
to openssh-...@mindrot.org
On 09.06.21 00:15, Damien Miller wrote:
> On Tue, 8 Jun 2021, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
>> Of the choices enumerated by Damien, SessionType seems the most
>> useful. I assume there should be a third value to designate a normal
>> interactive session. Although, I'm dubious about the ovbious choice of
>> "interactive."
>
> I was thinking "default" - not very imaginative, I know...
"The default" in a particular use case needn't be an interactive shell,
> On Tue, 8 Jun 2021, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
>> Of the choices enumerated by Damien, SessionType seems the most
>> useful. I assume there should be a third value to designate a normal
>> interactive session. Although, I'm dubious about the ovbious choice of
>> "interactive."
>
> I was thinking "default" - not very imaginative, I know...
nor an interactive *anything*. OpenSSH has at least two options already
that accept "auto" as a value ...
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
Damien Miller
Jun 9, 2021, 8:21:57 PM6/9/21
to Volker Diels-Grabsch, openssh-...@mindrot.org
On Tue, 8 Jun 2021, Volker Diels-Grabsch wrote:
> I'd prefer to rename NoShell to NoSession, and perhaps to do the same
> for the internal variable names for consistency. Then, we would have
> a one-to-one match of command line and configuration file, which is
> IMHO the least surprise for users already familiar with "-N" and "-s".
>
> However, I'm not opposed to introduce "SessionType=none/subsystem", in
> case you like me to implement it that way.
>
> How should we proceed from here? Which variant should I implement?
I think SessionType=none/subsystem/default is the way to go. I'll
> I'd prefer to rename NoShell to NoSession, and perhaps to do the same
> for the internal variable names for consistency. Then, we would have
> a one-to-one match of command line and configuration file, which is
> IMHO the least surprise for users already familiar with "-N" and "-s".
>
> However, I'm not opposed to introduce "SessionType=none/subsystem", in
> case you like me to implement it that way.
>
> How should we proceed from here? Which variant should I implement?
have some time to look at it next week, but if you want to implement
it then please don't let me stop you :)
Thanks again for your patience.
-d
Volker Diels-Grabsch
Jun 10, 2021, 12:47:25 PM6/10/21
to Damien Miller, openssh-...@mindrot.org
Hi Damien,
Damien Miller wrote:
> I think SessionType=none/subsystem/default is the way to go. I'll
> have some time to look at it next week, but if you want to implement
> it then please don't let me stop you :)
Okay, finished:
https://github.com/openssh/openssh-portable/pull/231
I also replaced the internal 2 flags with a single option enum (integer).
Please note one subtle consequence here:
Combining the flags in a single value means that it is no longer
possible to have the "no_shell_flag" (-N) and "subsystem_flag" (-s)
enabled at the same time. This is good in itself, and among others,
this means that edge cases, where both "-N" and "-s" are given to ssh,
are now handled in a more logical way: The last provided one wins.
Is that okay?
Or, do we needed backwards-compatibility-by-all-means here?
(Which would mean in this case: "-N" always takes precedence over "-s".)
Best regards,
Volker
--
Volker Diels-Grabsch
----<<<((()))>>>----
Damien Miller wrote:
> I think SessionType=none/subsystem/default is the way to go. I'll
> have some time to look at it next week, but if you want to implement
> it then please don't let me stop you :)
https://github.com/openssh/openssh-portable/pull/231
I also replaced the internal 2 flags with a single option enum (integer).
Please note one subtle consequence here:
Combining the flags in a single value means that it is no longer
possible to have the "no_shell_flag" (-N) and "subsystem_flag" (-s)
enabled at the same time. This is good in itself, and among others,
this means that edge cases, where both "-N" and "-s" are given to ssh,
are now handled in a more logical way: The last provided one wins.
Is that okay?
Or, do we needed backwards-compatibility-by-all-means here?
(Which would mean in this case: "-N" always takes precedence over "-s".)
Best regards,
Volker
--
Volker Diels-Grabsch
----<<<((()))>>>----
Reply all
Reply to author
Forward
0 new messages