Age | Commit message (Collapse) | Author |
|
> Are you sure you want to continue connecting (yes/no/[fingerprint])?
compare the fingerprint case sensitively; spotted Patrik Lundin
ok dtucker
|
|
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@
|
|
the agent supports them properly
|
|
from Pedro Martelletto
|
|
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@
|
|
|
|
"ssh-keygen -vyf /path/key"
|
|
is attached.
with Pedro Martelletto
|
|
|
|
|
|
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@
|
|
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
|
|
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@
|
|
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@
|
|
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@
|
|
|
|
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@
|
|
respect $SSH_ASKPASS_REQUIRE; ok markus@
|
|
if the user specified a custom extension then the everything would be
in order except the custom ones. bz3198 ok dtucker markus
|
|
default remains to not forward an agent, even when ssh_config enables
it. ok jmc dtucker markus
|
|
comments, which is the style we currently use, and gives too many
boring warnings.
ok djm
|
|
|
|
that recently got %k.
|
|
|
|
|
|
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)
|
|
allowing the file to be automagically split up in the configuration
(eg bz#1654). ok djm@, man page parts jmc@
|
|
- Reorder parameters list in the first usage() case
- Sentence rewording
ok dtucker@
jmc@ noticed usage() missed -a flag too
|
|
|
|
|
|
via $SSH_ASKPASS_REQUIRE, including force-enable/disable.
bz#69 ok markus@
|
|
|
|
|
|
|
|
|
|
|
|
SSH_CHANNEL_MUX_LISTENER; Specifically SSH_CHANNEL_MUX_PROXY channels
should not have this structure freed.
|
|
it here causes other problems
|
|
in chroot mode, the likely absence of a password database will cause
tilde_expand_filename() to fatal; ok dtucker@
|
|
after the session child process is forked(); ok dtucker@
|
|
select() loop; fixed theoretical case where busy sshd may ignore
timeouts from client; inspired by and ok dtucker
|
|
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@
|
|
ok dtucker
|
|
|
|
OK djm@
|
|
the change introduced a NULL deref in sshpkt_vfatal() (uses of ssh->kex after
calling ssh_packet_clear_keys())
|
|
outside ~/.ssh; with dtucker@
|
|
bz#3071; ok dtucker@
|
|
bz#3180; ok dtucker@
|
|
|