client
Click on the red underlined text to get to the source
... public keys in an implementation-independent fashion. This approach
allows client software to take on the burden of this configuration.
The Public Key Subsystem protocol is designed for extreme simplicity
...
... 2] and user authentication
protocols [3]. It provides a simple mechanism for the client to
manage public keys on the server.
...
... Public Key Subsystem provides a server-independent mechanism for
clients to add public keys, remove public keys, and list the current
...
... publickey"
Client implementations SHOULD reject this request; it is normally
sent only by the client.
...
... Client implementations SHOULD reject this request; it is normally
sent only by the client.
If want reply is TRUE, the server MUST respond with
...
... public key).
It is RECOMMENDED that clients request and check the reply for this
request.
...
... request/response-specific data, but does not include the length of
the length field itself. The client MUST receive acknowledgement of
each request prior to sending a new request.
...
... status messages are only sent
by the server (in response to requests from the client). This is the
only occasion on which the client sends a status message ...
... by the server (in response to requests from the client). This is the
only occasion on which the client sends a status message.
...
... SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the
client SHOULD provide an option to the user to overwrite the key. If
the overwrite field is true and the specified key already exists, but
cannot be overwritten, the server MUST return
...
... language for that attribute [6].
The client MAY specify more than one comment if it additionally
specifies a different language for each of those comments. The
...
... is in use. The command should be executed by the server when it
receives an "exec" or "shell" request from the client, in place of
the command or shell which would otherwise have been executed as a
result of that request. If the command string is empty, both "exec"
...
... critical.
In addition to the attributes specified by the client, the server MAY
provide a method for administrators ...
... requirement that the responses be in any particular
order. Whilst some server implementations may send the responses in
some order, client implementations should not rely on responses being
in any order.
...
...
If the client wishes to know which key attributes the server
supports, it sends:
...
... The "compulsory" field indicates whether this attribute will be
compulsorily applied to any added keys (irrespective of whether the
attribute has been specified by the client) due to administrative
settings on the server. If the server does not support
administrative settings of this nature, it MUST return false in the
...
... attacks.
This protocol provides a mechanism that allows client authentication
data to be uploaded and manipulated. It is the responsibility of the
server implementation to enforce any access controls that may be
...
... this protocol, whilst at the same time specifying fewer restrictions
for the new key than were previously present. Servers should take
care that when doing this, clients are not able to override presets
from the server's administrator.
...
... administrator.
This protocol requires the client to assume that the server will
correctly implement and observe attributes applied to keys.
Implementation errors in the server could cause clients ...
... client to assume that the server will
correctly implement and observe attributes applied to keys.
Implementation errors in the server could cause clients to authorize
keys for access they were not intended to have, or to apply fewer
restrictions than were intended.
...
