| Age | Commit message (Collapse) | Author |
|---|
|
- 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]
tweak language
|
|
[PROTOCOL]
fix an incorrect magic number and typo in PROTOCOL; bz#1688
report and fix from ueno AT unixuser.org
|
|
[PROTOCOL]
mention that eow and no-more-sessions extensions are sent only to
OpenSSH peers
|
|
[PROTOCOL]
grammar
|
|
[PROTOCOL]
clarify that eow@openssh.com is only sent on session channels
|
|
[PROTOCOL PROTOCOL.agent]
document the protocol used by ssh-agent; "looks ok" markus@
|
|
[PROTOCOL]
spelling fixes
|
|
[PROTOCOL]
document tun@openssh.com forwarding method
|
|
[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]
Use a $OpenBSD tag so our scripts will sync changes.
|
|
[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]
statvfs member fsid needs to be wider, increase it to 64 bits and
crank extension revision number to 2; prodded and ok dtucker@
|
|
[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@
|
