Skip to main content
Information Security

Return to Answer

replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link
Community Bot
Community Bot
  • 1

(After Q edit)

In SSHv2 (the only one anyone still uses) yes, both the (selected) host key and the client key if any are used only for authentication; the client software must support receiving (and verifying) the host's key type (in your example EC) and the host software must support receiving the client's key type (RSA).

The session key is created using ephemeral Diffie-Hellman (including ECDH or X25519 in modern systems) not the user-visible 'pubkey' files and algorithms, and the two data ciphers (and MACs if applicable) are negotiated separately and use working keys (and IVs if applicable) derived from the session key.

This is mostly described in RFC 4253RFC 4253 especially 6.5, 6.6, and 7. Some options are in other RFCs; see https://en.wikipedia.org/wiki/Secure_Shell#Standards_documentation or http://www.openssh.com/specs.html .

(After Q edit)

In SSHv2 (the only one anyone still uses) yes, both the (selected) host key and the client key if any are used only for authentication; the client software must support receiving (and verifying) the host's key type (in your example EC) and the host software must support receiving the client's key type (RSA).

The session key is created using ephemeral Diffie-Hellman (including ECDH or X25519 in modern systems) not the user-visible 'pubkey' files and algorithms, and the two data ciphers (and MACs if applicable) are negotiated separately and use working keys (and IVs if applicable) derived from the session key.

This is mostly described in RFC 4253 especially 6.5, 6.6, and 7. Some options are in other RFCs; see https://en.wikipedia.org/wiki/Secure_Shell#Standards_documentation or http://www.openssh.com/specs.html .

(After Q edit)

In SSHv2 (the only one anyone still uses) yes, both the (selected) host key and the client key if any are used only for authentication; the client software must support receiving (and verifying) the host's key type (in your example EC) and the host software must support receiving the client's key type (RSA).

The session key is created using ephemeral Diffie-Hellman (including ECDH or X25519 in modern systems) not the user-visible 'pubkey' files and algorithms, and the two data ciphers (and MACs if applicable) are negotiated separately and use working keys (and IVs if applicable) derived from the session key.

This is mostly described in RFC 4253 especially 6.5, 6.6, and 7. Some options are in other RFCs; see https://en.wikipedia.org/wiki/Secure_Shell#Standards_documentation or http://www.openssh.com/specs.html .

Source Link
dave_thompson_085
dave_thompson_085
  • 11.1k
  • 1
  • 31
  • 31

(After Q edit)

In SSHv2 (the only one anyone still uses) yes, both the (selected) host key and the client key if any are used only for authentication; the client software must support receiving (and verifying) the host's key type (in your example EC) and the host software must support receiving the client's key type (RSA).

The session key is created using ephemeral Diffie-Hellman (including ECDH or X25519 in modern systems) not the user-visible 'pubkey' files and algorithms, and the two data ciphers (and MACs if applicable) are negotiated separately and use working keys (and IVs if applicable) derived from the session key.

This is mostly described in RFC 4253 especially 6.5, 6.6, and 7. Some options are in other RFCs; see https://en.wikipedia.org/wiki/Secure_Shell#Standards_documentation or http://www.openssh.com/specs.html .