| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Deal with IP addresses (i.e. CheckHostIP)
Don't clobber known_hosts when nothing changed
ok markus@ as part of larger commit
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a hostkeys@openssh.com protocol extension (global request) for
a server to inform a client of all its available host key after
authentication has completed. The client may record the keys in
known_hosts, allowing it to upgrade to better host key algorithms
and a server to gracefully rotate its keys.
The client side of this is controlled by a UpdateHostkeys config
option (default on).
ok markus@
|
|
|
|
|
|
|
|
| |
known_hosts file or controlled subset thereof. This will
allow us to pull out some ugly and duplicated code, and
will be used to implement hostkey rotation later.
feedback and ok markus
|
|
|
|
| |
buffer/key API; mostly mechanical, ok markus@
|
| |
|
|
|
|
|
|
| |
which hostkeys are already recorded in known_hosts. This avoids
hostkey warnings when connecting to servers with new ECDSA keys
that are preferred by default; with markus@
|
|
|
|
|
|
|
|
|
|
|
| |
are trusted to authenticate users (in addition than doing it per-user
in authorized_keys).
Add a RevokedKeys option to sshd_config and a @revoked marker to
known_hosts to allow keys to me revoked and banned for user or host
authentication.
feedback and ok markus@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSSH certificate key types are not X.509 certificates, but a much
simpler format that encodes a public key, identity information and
some validity constraints and signs it with a CA key. CA keys are
regular SSH keys. This certificate style avoids the attack surface
of X.509 certificates and is very easy to deploy.
Certified host keys allow automatic acceptance of new host keys
when a CA certificate is marked as trusted in ~/.ssh/known_hosts.
see VERIFYING HOST KEYS in ssh(1) for details.
Certified user keys allow authentication of users when the signing
CA key is marked as trusted in authorized_keys. See "AUTHORIZED_KEYS
FILE FORMAT" in sshd(8) for details.
Certificates are minted using ssh-keygen(1), documentation is in
the "CERTIFICATES" section of that manpage.
Documentation on the format of certificates is in the file
PROTOCOL.certkeys
feedback and ok markus@
|
| |
|
|
|
|
| |
to improve privacy of which hosts user have been visiting; ok markus@ deraadt@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
see discussion at http://marc.theaimsgroup.com/?t=101069210100016&r=1&w=4
the ssharp mitm tool attacks users in a similar way, so i'd like to
pointed out again:
A MITM attack is always possible if the ssh client prints:
The authenticity of host 'bla' can't be established.
(protocol version 2 with pubkey authentication allows you to detect
MITM attacks)
|
| |
|
|
|
|
| |
and out of sync
|
|
|
|
|
| |
- () -> (void)
- no variable names
|
|
|
|
|
|
| |
- more strict prototypes, include necessary headers
- use paths.h/pathnames.h decls
- size_t typecase to int -> u_long
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
the details. everything is now under Tatu's licence (which I copied from his
readme), and/or the core-sdi bsd-ish thing for deattack, or various openbsd
developers under a 2-term bsd licence. We're not changing any rules, just
being accurate.
|
| |
|
|
|