the glob issue, which cannot be fully fixed and really requires completely
replacing scp with a completely different subsystem. team effort to find the
right words..
OpenBSD-Commit-ID: 58e1f72d292687f63eb357183036ee242513691c
when peer advertises a large window but is slow to consume the data we send
(e.g. because of a slow network)
reported by Pierre-Yves David
fix with & ok markus@
OpenBSD-Commit-ID: 1452771f5e5e768876d3bfe2544e3866d6ade216
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
djm@openbsd.org
deraadt@openbsd.org
Damien Miller
Philip Hands
Oleg
dtucker@openbsd.org
HARUYAMA Seigo
pedro martelletto
Darren Tucker
Sebastian Andrzej Siewior
jmc@openbsd.org