RFC 4819:Secure Shell Public Key Subsystem
RFC-Ref

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 ...
... The Public Key Subsystem is started by a client sending an SSH_MSG_CHANNEL ...
... To open the Public Key Subsystem, the client sends: byte SSH ...
... 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. ...


... If the client wishes to add a public key, the client sends: ...
... If the client wishes to add a public key, the client sends: string "add" ...
... 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 ...
... If the client wishes to remove a public key, the client ...
... client wishes to remove a public key, the client sends: string "remove ...
... If the client wishes to list the known public keys, the client sends: ...
... If the client wishes to list the known public keys, the client sends: string "list" ...
... 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. ...



Google
Web
RFC-Ref