when testing, make sure to include the relevant header files that
declare the types of the functions used by the test:
- stdio.h for printf();
- stdlib.h for exit();
- string.h for strcmp();
- unistd.h for unlink(), _exit(), fork(), getppid(), sleep().
prefer the default ordering if the user has a key that matches the
best-preference default algorithm.
feedback and ok markus@
OpenBSD-Commit-ID: a92dd7d7520ddd95c0a16786a7519e6d0167d35f
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.
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>.
> Are you sure you want to continue connecting (yes/no/[fingerprint])?
compare the fingerprint case sensitively; spotted Patrik Lundin
ok dtucker
OpenBSD-Commit-ID: 73097afee1b3a5929324e345ba4a4a42347409f2
autoreconf complains about underquoted definition of
OSSH_CHECK_HEADER_FOR_FIELD after aclocal.m4 has been and now is beeing
recreated.
Quote OSSH_CHECK_HEADER_FOR_FIELD as suggested.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
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
1cfd5c06ef ("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>
the data needed to verify the attestation. Previously we were missing the
"authenticator data" that is included in the signature.
spotted by Ian Haken
feedback Pedro Martelletto and Ian Haken; ok markus@
OpenBSD-Commit-ID: 8439896e63792b2db99c6065dd9a45eabbdb7e0a
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@
OpenBSD-Commit-ID: 2d0b10c69fad5d8fda4c703e7c6804935289378b
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.
joint work with Pedro Martelletto; ok markus@
OpenBSD-Commit-ID: 863182d38ef075bad1f7d20ca485752a05edb727
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.
from Pedro Martelletto; ok markus@ and myself
OpenBSD-Commit-ID: 201c46ccdd227cddba3d64e1bdbd082afa956517
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.
Work by Pedro Martelletto; ok myself and markus@
OpenBSD-Commit-ID: 637d3049ced61b7a9ee796914bbc4843d999a864
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.
feedback and ok markus@
OpenBSD-Commit-ID: 3a2313aae153e043d57763d766bb6d55c4e276e6
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@
OpenBSD-Commit-ID: 57fd461e4366f87c47502c5614ec08573e6d6a15
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@
OpenBSD-Commit-ID: 792e71cacbbc25faab5424cf80bee4a006119f94
* 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
Previously if the user specified a custom extension then the everything would
be in order except the custom ones. bz3198 ok dtucker markus
OpenBSD-Commit-ID: d97deb90587b06cb227c66ffebb2d9667bf886f0
Damien Miller
djm@openbsd.org
pedro martelletto
dtucker@openbsd.org
Darren Tucker
Sebastian Andrzej Siewior
jmc@openbsd.org
cheloha@openbsd.org
Stefan Schindler