2007-09-29 14:20:55 +00:00
|
|
|
\A{sshnames} SSH-2 names specified for PuTTY
|
|
|
|
|
|
|
|
There are various parts of the SSH-2 protocol where things are specified
|
|
|
|
using a textual name. Names ending in \cw{@putty.projects.tartarus.org}
|
|
|
|
are reserved for allocation by the PuTTY team. Allocated names are
|
|
|
|
documented here.
|
|
|
|
|
2008-11-30 21:35:33 +00:00
|
|
|
\H{sshnames-channel} Connection protocol channel request names
|
2007-09-29 14:20:55 +00:00
|
|
|
|
2008-11-30 21:35:33 +00:00
|
|
|
These names can be sent in a \cw{SSH_MSG_CHANNEL_REQUEST} message.
|
2007-09-29 14:20:55 +00:00
|
|
|
|
|
|
|
\dt \cw{simple@putty.projects.tartarus.org}
|
|
|
|
|
2008-11-30 21:35:33 +00:00
|
|
|
\dd This is sent by a client to announce that it will not have more than
|
|
|
|
one channel open at a time in the current connection (that one being
|
|
|
|
the one the request is sent on). The intention is that the server,
|
|
|
|
knowing this, can set the window on that one channel to something very
|
|
|
|
large, and leave flow control to TCP. There is no message-specific data.
|
2007-09-29 14:20:55 +00:00
|
|
|
|
2008-01-09 19:59:16 +00:00
|
|
|
\dt \cw{winadj@putty.projects.tartarus.org}
|
2007-09-29 14:20:55 +00:00
|
|
|
|
|
|
|
\dd PuTTY sends this request along with some
|
|
|
|
\cw{SSH_MSG_CHANNEL_WINDOW_ADJUST} messages as part of its window-size
|
2008-11-30 21:35:33 +00:00
|
|
|
tuning. It can be sent on any type of channel. There is no
|
|
|
|
message-specific data. Servers MUST treat it as an unrecognised request
|
|
|
|
and respond with \cw{SSH_MSG_CHANNEL_FAILURE}.
|
2007-09-29 14:20:55 +00:00
|
|
|
|
2014-10-21 11:33:33 +00:00
|
|
|
\lcont{
|
|
|
|
(Some SSH servers get confused by this message, so there is a
|
|
|
|
bug-compatibility mode for disabling it. See \k{config-ssh-bug-winadj}.)
|
|
|
|
}
|
|
|
|
|
2007-09-29 14:20:55 +00:00
|
|
|
\H{sshnames-kex} Key exchange method names
|
|
|
|
|
|
|
|
\dt \cw{rsa-sha1-draft-00@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa-sha256-draft-00@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa1024-sha1-draft-01@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa1024-sha256-draft-01@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa2048-sha256-draft-01@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa1024-sha1-draft-02@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa2048-sha512-draft-02@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa1024-sha1-draft-03@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa2048-sha256-draft-03@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa1024-sha1-draft-04@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{rsa2048-sha256-draft-04@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dd These appeared in various drafts of what eventually became RFC\_4432.
|
|
|
|
They have been superseded by \cw{rsa1024-sha1} and \cw{rsa2048-sha256}.
|
|
|
|
|
|
|
|
\H{sshnames-encrypt} Encryption algorithm names
|
|
|
|
|
|
|
|
\dt \cw{arcfour128-draft-00@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dt \cw{arcfour256-draft-00@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dd These were used in drafts of what eventually became RFC\_4345.
|
|
|
|
They have been superseded by \cw{arcfour128} and \cw{arcfour256}.
|
2021-04-04 12:27:05 +00:00
|
|
|
|
|
|
|
\H{sshnames-agent} Agent extension request names
|
|
|
|
|
|
|
|
The SSH agent protocol, which is only specified in an Internet-Draft
|
|
|
|
at the time of writing
|
|
|
|
(\W{https://tools.ietf.org/html/draft-miller-ssh-agent}\cw{draft-miller-ssh-agent}),
|
|
|
|
defines an extension mechanism. These names can be sent in an
|
|
|
|
\cw{SSH_AGENTC_EXTENSION} message.
|
|
|
|
|
|
|
|
\dt \cw{add-ppk@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dd The payload is a single SSH-2 \cw{string} containing a keypair in
|
|
|
|
the PPK format defined in \k{ppk}. Compared to the standard
|
|
|
|
\cw{SSH_AGENTC_ADD_IDENTITY}, this extension allows adding keys in
|
|
|
|
encrypted form, with the agent requesting a decryption passphrase from
|
|
|
|
the user on demand, and able to revert the key to encrypted form.
|
|
|
|
|
|
|
|
\dt \cw{reencrypt@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dd The payload is a single SSH-2 \cw{string} specifying a public key
|
|
|
|
blob, as in \cw{SSH_AGENTC_REMOVE_IDENTITY}. Requests that the agent
|
|
|
|
forget any cleartext form of a specific key.
|
|
|
|
|
|
|
|
\lcont{
|
|
|
|
Returns \cw{SSH_AGENT_SUCCESS} if the agent ended up holding the key
|
|
|
|
only in encrypted form (even if it was already encrypted); returns
|
|
|
|
\cw{SSH_AGENT_EXTENSION_FAILURE} if not (if it wasn't held by the
|
|
|
|
agent at all, or only in cleartext form).
|
|
|
|
}
|
|
|
|
|
|
|
|
\dt \cw{reencrypt-all@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dd No payload. Requests that the agent forget the cleartext form of
|
|
|
|
any keys for which it holds an encrypted form.
|
|
|
|
|
|
|
|
\lcont{
|
|
|
|
If the agent holds any keys with an encrypted form (or no keys at all),
|
|
|
|
returns \cw{SSH_AGENT_SUCCESS} to indicate that no such keys are now
|
|
|
|
held in cleartext form, followed by a \cw{uint32} specifying how many keys
|
|
|
|
remain in cleartext form (because the agent didn't hold an encrypted
|
|
|
|
form for them). If the agent holds nothing but keys in cleartext form,
|
|
|
|
returns \cw{SSH_AGENT_EXTENSION_FAILURE}.
|
|
|
|
}
|
|
|
|
|
|
|
|
\dt \cw{list-extended@putty.projects.tartarus.org}
|
|
|
|
|
|
|
|
\dd No payload. Returns \cw{SSH_AGENT_SUCCESS} followed by a list of
|
|
|
|
identities similar to \cw{SSH_AGENT_IDENTITIES_ANSWER}, except that
|
|
|
|
each key has an extra SSH-2 \cw{string} at the end. Currently that
|
|
|
|
\cw{string} contains a single \cw{uint32} flags word, with the
|
|
|
|
following bits defined:
|
|
|
|
|
|
|
|
\lcont{
|
|
|
|
\dt Bit 0
|
|
|
|
|
|
|
|
\dd If set, key is held with an encrypted form (so that the
|
|
|
|
\c{reencrypt} extension can do something useful with it).
|
|
|
|
|
|
|
|
\dt Bit 1
|
|
|
|
|
|
|
|
\dd If set, key's cleartext form is not currently held (so the
|
|
|
|
user will have to supply a passphrase before the key can be used).
|
|
|
|
}
|