| Age | Commit message (Collapse) | Author |
|---|
|
by jmc@ a while back
CVS ----------------------------------------------------------------------
|
|
|
|
hardcoding lowdelay/throughput.
bz#1733 patch from philipp AT redfish-solutions.com; ok markus@ deraadt@
|
|
|
|
selection of which key exchange methods are used by ssh(1) and sshd(8)
and their order of preference.
ok markus@
|
|
host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
better performance than plain DH and DSA at the same equivalent symmetric
key length, as well as much shorter keys.
Only the mandatory sections of RFC5656 are implemented, specifically the
three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and
ECDSA. Point compression (optional in RFC5656 is NOT implemented).
Certificate host and user keys using the new ECDSA key types are supported.
Note that this code has not been tested for interoperability and may be
subject to change.
feedback and ok markus@
|
|
|
|
ok markus@
|
|
AuthorizedKeysFile AuthorizedPrincipalsFile
HostbasedUsesNameFromPacketOnly PermitTunnel
bz#1764; feedback from imorgan AT nas.nasa.gov; ok dtucker@
|
|
|
|
in certificates. Currently, a certificate must include the a user's name
to be accepted for authentication. This change adds the ability to
specify a list of certificate principal names that are acceptable.
When authenticating using a CA trusted through ~/.ssh/authorized_keys,
this adds a new principals="name1[,name2,...]" key option.
For CAs listed through sshd_config's TrustedCAKeys option, a new config
option "AuthorizedPrincipalsFile" specifies a per-user file containing
the list of acceptable names.
If either option is absent, the current behaviour of requiring the
username to appear in principals continues to apply.
These options are useful for role accounts, disjoint account namespaces
and "user@realm"-style naming policies in certificates.
feedback and ok 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@
|
|
with "route exec" or "nc -V" as a proxycommand. "route exec" also ensures
that trafic such as DNS lookups stays withing the specified routingdomain.
For example (from reyk):
# route -T 2 exec /usr/sbin/sshd
or inherited from the parent process
$ route -T 2 exec sh
$ ssh 10.1.2.3
ok deraadt@ markus@ stevesk@ reyk@
|
|
|
|
consistent with other options.
NOTE: if you currently use RDomain in the ssh client or server config,
or ssh/sshd -o, you must update to use RoutingDomain.
ok markus@ djm@
|
|
a question on openssh-unix-dev. ok jmc@
|
|
and ownership are always checked when chrooting. bz#1532
|
|
|
|
ok markus@
|
|
|
|
ok deraadt
|
|
|
|
earlier version; tweaks and ok jmc@
|
|
|
|
markus@
|
|
|
|
|
|
|
|
|
|
ok djm
|
|
method using the J-PAKE protocol described in F. Hao, P. Ryan,
"Password Authenticated Key Exchange by Juggling", 16th Workshop on
Security Protocols, Cambridge, April 2008.
This method allows password-based authentication without exposing
the password to the server. Instead, the client and server exchange
cryptographic proofs to demonstrate of knowledge of the password while
revealing nothing useful to an attacker or compromised endpoint.
This is experimental, work-in-progress code and is presently
compiled-time disabled (turn on -DJPAKE in Makefile.inc).
"just commit it. It isn't too intrusive." deraadt@
|
|
requested in PR3891; ok dtucker@
|
|
bits; prodded by & ok dtucker@ ok deraadt@
|
|
|
|
|
|
|
|
|
|
full support for negation and fall-back to classic wildcard matching.
For example:
Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*
PasswordAuthentication yes
addrmatch.c code mostly lifted from flowd's addr.c
feedback and ok dtucker@
|
|
a sshd_config MaxSessions knob. This is useful for disabling
login/shell/subsystem access while leaving port-forwarding working
(MaxSessions 0), disabling connection multiplexing (MaxSessions 1) or
simply increasing the number of allows multiplexed sessions.
Because some bozos are sure to configure MaxSessions in excess of the
number of available file descriptors in sshd (which, at peak, might be
as many as 9*MaxSessions), audit sshd to ensure that it doesn't leak fds
on error paths, and make it fail gracefully on out-of-fd conditions -
sending channel errors instead of than exiting with fatal().
bz#1090; MaxSessions config bits and manpage from junyer AT gmail.com
ok markus@
|
|
|
|
context), to specify if agents should be permitted on the server.
As the man page states:
``Note that disabling Agent forwarding does not improve security
unless users are also denied shell access, as they can always install
their own forwarders.''
ok djm@, ok and a mild frown markus@
|
|
|
|
spotted by jmc@
|
|
there). Spotted by Minstrel AT minstrel.org.uk
|
|
from dtucker@ ok deraadt@ djm@
|
|
of a typo in rcs.c;
|
|
|
