Damien Miller [Fri, 18 Sep 2020 04:55:48 +0000 (14:55 +1000)]
control over the colours in gnome-ssh-askpass[23]
Optionally set the textarea colours via $GNOME_SSH_ASKPASS_FG_COLOR and
$GNOME_SSH_ASKPASS_BG_COLOR. These accept the usual three or six digit
hex colours.
Damien Miller [Fri, 18 Sep 2020 04:50:38 +0000 (14:50 +1000)]
focus improvement for gnome-ssh-askpass[23]
When serving a SSH_ASKPASS_PROMPT=none information dialog, ensure
then <enter> doesn't immediately close the dialog. Instead, require an
explicit <tab> to reach the close button, or <esc>.
The `aclocal' step is skipped during `autoreconf' because aclocal.m4 is
present.
Move the current aclocal.m4 which contains local macros into the m4/
folder. With this change the aclocal.m4 will be re-created during
changes to the m4/ macro.
This is needed so the `aclocal' can fetch m4 macros from the system if
they are references in the configure script. This is a prerequisite to
use PKG_CHECK_MODULES.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
BROKEN_MMAP is no longer defined since commit 1cfd5c06efb12 ("Remove portability support for mmap")
this commit also removed other HAVE_MMAP user. I didn't find anything
that defines HAVE_MMAP. The check does not trigger because compression
on server side is by default COMP_DELAYED (2) so it never triggers.
Remove remaining HAVE_MMAP and BROKEN_MMAP bits.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
upstream: Check that the addresses supplied to Match Address and
Match LocalAddress are valid when parsing in config-test mode. This will
catch address/mask mismatches before they cause problems at runtime. Found by
Daniel Stocker, ok djm@
djm@openbsd.org [Thu, 27 Aug 2020 01:08:45 +0000 (01:08 +0000)]
upstream: Request PIN ahead of time for certain FIDO actions
When we know that a particular action will require a PIN, such as
downloading resident keys or generating a verify-required key, request
the PIN before attempting it.
djm@openbsd.org [Thu, 27 Aug 2020 01:08:19 +0000 (01:08 +0000)]
upstream: preserve verify-required for resident FIDO keys
When downloading a resident, verify-required key from a FIDO token,
preserve the verify-required in the private key that is written to
disk. Previously we weren't doing that because of lack of support
in the middleware API.
djm@openbsd.org [Thu, 27 Aug 2020 01:07:51 +0000 (01:07 +0000)]
upstream: major rework of FIDO token selection logic
When PINs are in use and multiple FIDO tokens are attached to a host, we
cannot just blast requests at all attached tokens with the PIN specified
as this will cause the per-token PIN failure counter to increment. If
this retry counter hits the token's limit (usually 3 attempts), then the
token will lock itself and render all (web and SSH) of its keys invalid.
We don't want this.
So this reworks the key selection logic for the specific case of
multiple keys being attached. When multiple keys are attached and the
operation requires a PIN, then the user must touch the key that they
wish to use first in order to identify it.
This may require multiple touches, but only if there are multiple keys
attached AND (usually) the operation requires a PIN. The usual case of a
single key attached should be unaffected.
djm@openbsd.org [Thu, 27 Aug 2020 01:07:09 +0000 (01:07 +0000)]
upstream: support for requiring user verified FIDO keys in sshd
This adds a "verify-required" authorized_keys flag and a corresponding
sshd_config option that tells sshd to require that FIDO keys verify the
user identity before completing the signing/authentication attempt.
Whether or not user verification was performed is already baked into the
signature made on the FIDO token, so this is just plumbing that flag
through and adding ways to require it.
djm@openbsd.org [Thu, 27 Aug 2020 01:06:18 +0000 (01:06 +0000)]
upstream: support for user-verified FIDO keys
FIDO2 supports a notion of "user verification" where the user is
required to demonstrate their identity to the token before particular
operations (e.g. signing). Typically this is done by authenticating
themselves using a PIN that has been set on the token.
This adds support for generating and using user verified keys where
the verification happens via PIN (other options might be added in the
future, but none are in common use now). Practically, this adds
another key generation option "verify-required" that yields a key that
requires a PIN before each authentication.
feedback markus@ and Pedro Martelletto; ok markus@
djm@openbsd.org [Tue, 11 Aug 2020 09:49:57 +0000 (09:49 +0000)]
upstream: let ssh_config(5)'s AddKeysToAgent keyword accept a time
limit for keys in addition to its current flag options. Time-limited keys
will automatically be removed from ssh-agent after their expiry time has
passed; ok markus@
* Only use heimdal kerberos implementation
* Fetch yubico/libfido2 (see: https://github.com/Yubico/libfido2)
* Add one target for
* all features
* each feature alone
* no features
Darren Tucker [Tue, 28 Jul 2020 09:40:30 +0000 (19:40 +1000)]
Use argv in OSSH_CHECK_CFLAG_COMPILE test.
configure.ac is not detecting -Wextra in compilers that implement the
option. The problem is that -Wextra implies -Wunused-parameter, and the
C excerpt used by aclocal.m4 does not use argv. Patch from pedro at
ambientworks.net, ok djm@
upstream: Add a '%k' TOKEN that expands to the effective HostKey of
the destination. This allows, eg, keeping host keys in individual files
using "UserKnownHostsFile ~/.ssh/known_hosts.d/%k". bz#1654, ok djm@, jmc@
(man page bits)
Damien Miller [Fri, 17 Jul 2020 03:15:50 +0000 (13:15 +1000)]
detect Linux/X32 systems
This is a frankenstein monster of AMD64 instructions/calling conventions
but with a 4GB address space. Allegedly deprecated but people still run
into it causing weird sandbox failures, e.g. bz#3085
upstream: Only reset the serveralive check when we receive traffic from
the server and ignore traffic from a port forwarding client, preventing a
client from keeping a connection alive when it should be terminated. Based
on a patch from jxraynor at gmail.com via openssh-unix-dev and bz#2265, ok
djm@