[readconf.c readconf.h ssh.c ssh_config.5 sshconnect.c sshconnect2.c]
Remove undocumented legacy options UserKnownHostsFile2 and
GlobalKnownHostsFile2 by making UserKnownHostsFile/GlobalKnownHostsFile
accept multiple paths per line and making their defaults include
known_hosts2; ok markus
[auth.c hostfile.c hostfile.h ssh.c ssh_config.5 sshconnect.c]
[sshconnect.h sshconnect2.c]
automatically order the hostkeys requested by the client based on
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@
[kex.c kex.h kexecdh.c kexecdhc.c kexecdhs.c readconf.c readconf.h]
[servconf.c servconf.h ssh_config.5 sshconnect2.c sshd.c sshd_config.5]
add a KexAlgorithms knob to the client and server configuration to allow
selection of which key exchange methods are used by ssh(1) and sshd(8)
and their order of preference.
ok markus@
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c]
[authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c]
[monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c]
[ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c]
[ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h]
[ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5]
[uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c]
Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
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@
[sshconnect2.c]
bz#1502: authctxt.success is declared as an int, but passed by
reference to function that accepts sig_atomic_t*. Convert it to
the latter; ok markus@ dtucker@
[PROTOCOL.certkeys auth-options.c auth-options.h auth-rsa.c]
[auth2-pubkey.c authfd.c key.c key.h myproposal.h ssh-add.c]
[ssh-agent.c ssh-dss.c ssh-keygen.1 ssh-keygen.c ssh-rsa.c]
[sshconnect.c sshconnect2.c sshd.c]
revised certificate format ssh-{dss,rsa}-cert-v01@openssh.com with the
following changes:
move the nonce field to the beginning of the certificate where it can
better protect against chosen-prefix attacks on the signature hash
Rename "constraints" field to "critical options"
Add a new non-critical "extensions" field
Add a serial number
The older format is still support for authentication and cert generation
(use "ssh-keygen -t v00 -s ca_key ..." to generate a v00 certificate)
ok markus@
[sshconnect2.c]
show the key type that we are offering in debug(), helps distinguish
between certs and plain keys as the path to the private key is usually
the same.
- djm@cvs.openbsd.org 2010/02/26 20:29:54
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys addrmatch.c auth-options.c]
[auth-options.h auth.h auth2-pubkey.c authfd.c dns.c dns.h hostfile.c]
[hostfile.h kex.h kexdhs.c kexgexs.c key.c key.h match.h monitor.c]
[myproposal.h servconf.c servconf.h ssh-add.c ssh-agent.c ssh-dss.c]
[ssh-keygen.1 ssh-keygen.c ssh-rsa.c ssh.1 ssh.c ssh2.h sshconnect.c]
[sshconnect2.c sshd.8 sshd.c sshd_config.5]
Add support for certificate key types for users and hosts.
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 sh/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@
[authfile.c sshconnect2.c]
Do not prompt for a passphrase if we fail to open a keyfile, and log the
reason the open failed to debug.
bz #1693, found by tj AT castaglia org, ok djm@
[sshconnect2.c channels.c sshconnect.c]
Set close-on-exec on various descriptors so they don't get leaked to
child processes. bz #1643, patch from jchadima at redhat, ok deraadt.
[sshconnect2.c]
disallow a hostile server from checking jpake auth by sending an
out-of-sequence success message. (doesn't affect code enabled by default)
[auth2-jpake.c jpake.c jpake.h monitor_wrap.c monitor_wrap.h schnorr.c]
[sshconnect2.c]
refactor the (disabled) Schnorr proof code to make it a little more
generally useful
[auth.h auth2.c monitor.c monitor.h monitor_wrap.c monitor_wrap.h]
[readconf.c readconf.h servconf.c servconf.h ssh2.h ssh_config.5]
[sshconnect2.c sshd_config.5 jpake.c jpake.h schnorr.c auth2-jpake.c]
[Makefile.in]
Add support for an experimental zero-knowledge password authentication
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@
[sshconnect2.c]
Repair strnvis() buffersize of 4*n+1, with termination gauranteed by the
function.
spotted by des@freebsd, who commited an incorrect fix to the freebsd tree
and (as is fairly typical) did not report the problem to us. But this fix
is correct.
ok djm
[readconf.c readconf.h sshconnect2.c]
promote rekeylimit to a int64 so it can hold the maximum useful limit
of 2^32; report and patch from Jan.Pechanec AT Sun.COM, ok dtucker@
[sshconnect2.c]
fall back to gethostname() when the outgoing connection is not
on a socket, such as is the case when ProxyCommand is used.
Gives hostbased auth an opportunity to work; bz#616, report
and feedback stuart AT kaloram.com; ok markus@
[sshconnect2.c]
Fix regression where SSH2 banner is printed at loglevels ERROR and FATAL
where previously it weren't. bz #1221, found by Dean Kopesky, ok djm@
[authfile.c authfile.h sshconnect2.c ssh.c sshconnect1.c]
Prevent ssh from trying to open private keys with bad permissions more than
once or prompting for their passphrases (which it subsequently ignores
anyway), similar to a previous change in ssh-add. bz #1186, ok djm@
[auth-bsdauth.c auth-skey.c auth.c auth2-chall.c channels.c]
[clientloop.c deattack.c gss-genr.c kex.c key.c misc.c moduli.c]
[monitor.c monitor_wrap.c packet.c scard.c sftp-server.c ssh-agent.c]
[ssh-keyscan.c ssh.c sshconnect.c sshconnect2.c sshd.c uuencode.c]
[xmalloc.c xmalloc.h]
introduce xcalloc() and xasprintf() failure-checked allocations
functions and use them throughout openssh
xcalloc is particularly important because malloc(nmemb * size) is a
dangerous idiom (subject to integer overflow) and it is time for it
to die
feedback and ok deraadt@
[kex.c kex.h monitor.c myproposal.h ssh-keyscan.c sshconnect2.c sshd.c]
Implement the diffie-hellman-group-exchange-sha256 key exchange method
using the SHA256 code in libc (and wrapper to make it into an OpenSSL
EVP), interop tested against CVS PuTTY
NB. no portability bits committed yet
- djm@cvs.openbsd.org 2005/08/30 22:08:05
[gss-serv.c sshconnect2.c]
destroy credentials if krb5_kuserok() call fails. Stops credentials being
delegated to users who are not authorised for GSSAPIAuthentication when
GSSAPIDeletegateCredentials=yes and another authentication mechanism
succeeds; bz#1073 reported by paul.moore AT centrify.com, fix by
simon AT sxw.org.uk, tested todd@ biorn@ jakob@; ok deraadt@
