[PROTOCOL sftp-client.c sftp-client.h sftp-server.c sftp.1 sftp.c]
fsync@openssh.com protocol extension for sftp-server
client support to allow calling fsync() faster successful transfer
patch mostly by imorgan AT nas.nasa.gov; bz#1798
"fine" markus@ "grumble OK" deraadt@ "doesn't sound bad to me" millert@
[PROTOCOL authfile.c cipher.c cipher.h kex.c kex.h monitor_wrap.c]
[myproposal.h packet.c ssh_config.5 sshd_config.5]
support AES-GCM as defined in RFC 5647 (but with simpler KEX handling)
ok and feedback djm@
[PROTOCOL authfile.c cipher.c cipher.h kex.h mac.c myproposal.h]
[packet.c ssh_config.5 sshd_config.5]
add encrypt-then-mac (EtM) modes to openssh by defining new mac algorithms
that change the packet format and compute the MAC over the encrypted
message (including the packet size) instead of the plaintext data;
these EtM modes are considered more secure and used by default.
feedback and ok djm@
[sftp-server.c sftp.1 sftp-client.h sftp.c PROTOCOL sftp-client.c]
add a protocol extension to support a hard link operation. It is
available through the "ln" command in the client. The old "ln"
behaviour of creating a symlink is available using its "-s" option
or through the preexisting "symlink" command; based on a patch from
miklos AT szeredi.hu in bz#1555; 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@
- 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@
[PROTOCOL ssh.c serverloop.c]
Add a no-more-sessions@openssh.com global request extension that the
client sends when it knows that it will never request another session
(i.e. when session multiplexing is disabled). This allows a server to
disallow further session requests and terminate the session.
Why would a non-multiplexing client ever issue additional session
requests? It could have been attacked with something like SSH'jack:
http://www.storm.net.nz/projects/7
feedback & ok markus
[PROTOCOL]
Have the sftp client store the statvfs replies in wire format,
which prevents problems when the server's native sizes exceed the
client's.
Also extends the sizes of the remaining 32bit wire format to 64bit,
they're specified as unsigned long in the standard.
[PROTOCOL]
document our protocol extensions and deviations; ok markus@
- djm@cvs.openbsd.org 2008/05/17 01:31:56
[PROTOCOL]
grammar and correctness fixes from stevesk@
Damien Miller
Darren Tucker