Three distinct responsibilities

SSH transport provides server authentication, confidentiality and integrity, normally over a reliable byte stream. User authentication identifies the client-side user, after which the connection protocol carries services.

Establishing an encrypted transport is therefore different from being authorized for an account. Host credentials identify the server; user credentials are evaluated separately by the server’s account and permission rules.

References: [1] [2]

Authentication and session binding

Defined methods include public-key and password authentication. The client identifies a user and requested service while the server controls which methods can proceed; public-key authentication proves private-key possession rather than uploading the private key.

Server identity matters as well. An encrypted exchange without a trustworthy host-key association does not by itself exclude an active intermediary substituting the destination.

The public-key signature is bound to the SSH session and request: RFC 4252 includes the session identifier, user name, requested service and key in the signed data. An optional query asking whether a key is acceptable does not prove private-key possession. Actual authentication requires the signature, and the server can still require additional methods. Public-key identification, proof of possession and account authorization therefore remain separate steps.

References: [1] [2] [4]

Several channels in one connection

The connection protocol multiplexes terminals and forwarded connections as logical channels. Each side assigns channel numbers, and windows and packet-size limits regulate channel data.

Opening a secure connection does not automatically grant every service. Terminal, command and forwarding permissions remain subject to server policy; transport mechanisms do not replace authorization.

References: [3]