6

Everything works, ssh connects using private-public ssh key pair.
Just few things in ssh -v Ora2 output isn't clear for me.

This is complete ssh -v Ora2 output:

PS C:\Users\roeslermichal> ssh -v Ora2
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Reading configuration data C:\\Users\\roeslermichal/.ssh/config
debug1: C:\\Users\\roeslermichal/.ssh/config line 19: Applying options for Ora2
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 10.32.81.218 [10.32.81.218] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\roeslermichal\\.ssh\\poczt_id_ed25519 type 3
debug1: identity file C:\\Users\\roeslermichal\\.ssh\\poczt_id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.32.81.218:22 as 'michal'
debug1: load_hostkeys: fopen C:\\Users\\roeslermichal/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:jQ2i6lqzzZnhdPc+GKQCS6iiCD5W/2wDzhLvigIlytg
debug1: load_hostkeys: fopen C:\\Users\\roeslermichal/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: Host '10.32.81.218' is known and matches the ED25519 host key.
debug1: Found key in C:\\Users\\roeslermichal/.ssh/known_hosts:10
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\roeslermichal\\.ssh\\poczt_id_ed25519 ED25519 SHA256:eQBpsX9pvzP6RuorzRWhlK2s4sOEdj3KrgME3TGeSMU explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\roeslermichal\\.ssh\\poczt_id_ed25519 ED25519 SHA256:eQBpsX9pvzP6RuorzRWhlK2s4sOEdj3KrgME3TGeSMU explicit
debug1: Server accepts key: C:\\Users\\roeslermichal\\.ssh\\poczt_id_ed25519 ED25519 SHA256:eQBpsX9pvzP6RuorzRWhlK2s4sOEdj3KrgME3TGeSMU explicit
debug1: Authentication succeeded (publickey).
Authenticated to 10.32.81.218 ([10.32.81.218]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching C:\\Users\\roeslermichal/.ssh/known_hosts for 10.32.81.218 / (none)
debug1: client_input_hostkeys: searching C:\\Users\\roeslermichal/.ssh/known_hosts2 for 10.32.81.218 / (none)
debug1: client_input_hostkeys: hostkeys file C:\\Users\\roeslermichal/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: Remote: /home/michal/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/michal/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Activate the web console with: systemctl enable --now cockpit.socket

I understand most of it, but few lines require some explanation.

  1. Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
    I don't understand what $SSH_SK_PROVIDER is, and what wasn't resolved at this stage.
    What is getting disabled??
    I mean, ssh just read ssh config file from my Windows 11 laptop and applied Ora2 settings.
    It's not even connected yet, so what authentication are we talking about so early in the process.
    What $SSH_SK_PROVIDER is ?
  2. Please explain these two lines for me:
    SSH2_MSG_KEXINIT sent
    SSH2_MSG_KEXINIT received
    I don't know what SSH2_MSG_KEXINIT is?
    Is it necessary?
    I'm just using private-public key pair authentication.
    Can I turn SSH2_MSG_KEXINIT off??
michal roesler
  • 195

1 Answers1

1

TL;DR:

  • SSH_SK_PROVIDER is only relevant if using hardware keys, and can otherwise be ignored.
  • SSH2_MSG_KEXINIT is a key part of the SSH communication and should not be touched.

DETAILED EXPLANATION

SSH_SK_PROVIDER

Per the release notes for OpenSSH 9:

FIDO tokens are most commonly connected via USB but may be attached via other means such as Bluetooth or NFC. In OpenSSH, communication with the token is managed via a middleware library, specified by the SecurityKeyProvider directive in ssh/sshd_config(5) or the $SSH_SK_PROVIDER environment variable for ssh-keygen(1) and ssh-add(1). The API for this middleware is documented in the sk-api.h and PROTOCOL.u2f files in the source distribution.

And the ssh-add manpage says:

SSH_SK_PROVIDER

Specifies a path to a library that will be used when loading any FIDO authenticator-hosted keys, overriding the default of using the built-in USB HID support.

In other words, that variable is only used if your ssh-agent is configured to use USB hardware keys as a source of authentication. Therefore, the variable is expected to be empty when not using hardware keys.

SSH2_MSG_KEXINIT

SSH2_MSG_KEXINIT is part of the Key-Exchange handshake, which is how your local ssh-agent and the remote ssh-daemon establish a secure communication channel. Specifically, the variable SSH2_MSG_KEXINIT is an integer constant with a value of 20, and is used in the SSH code to identify Key Exchange packets while communicating with the remote host (see ssh/ssh_api.c and ssh/packet.c in the libopenssh codebase).

SSH HISTORY

On a fundamental level, the Secure Shell (SSH) protocol works by exchanging asymmetric cryptographic keys between two servers (the "local" and the "remote", sometimes referred to as the "client" and "host"). These keys are then used to encrypt messages, which is what makes the connection secure.

Prior to SSH, the Telnet protocol was commonly used for remote shells, and later rsh (Remote Shell) became popular. However, Telnet and rsh both sent messages in cleartext, making it easy to intercept messages using promiscuous network adapters. The Secure Shell protocol was developed to prevent bad actors from reading potentially sensitive messages (e.g. passwords).

SSH utilizes a process called Asymmetric Key Exchange (now generalized as Public Key Cryptography) to securely exchange cryptographic keys over insecure channels. The first method for this was the Diffie–Hellman–Merkle algorithm, however as cryptography and cryptanalysis (aka code-breaking) methods have improved, other more secure (and more efficient) algorithms have become preferred.

In order to allow backward compatibility between newer ssh-agents and older ssh-daemons, the SSH protocol defines a negotiation process known as the SSH Handshake, which allows the local and remote services to define what cryptography algorithms they are able to use, and eventually the two servers will agree on a common algorithm (or, if no common algorithm exists, the connection will simply fail) and the actual Key Exchange can begin.

If the SSH2_MSG_KEXINIT appears in an SSH data, it indicates to the recipient that a new cryptographic Public Key is being transmitted, and prompts the recipient SSH service to utilize to the new key once it has been received. This is used during the initial Handshake, but it can also occur at any if one of the servers decides that it needs to "rotate" the keys (which may be done periodically during the session to further mitigate decryption attacks). If the Key Exchange fails, or the SSH2_MSG_KEXINIT message is never received, then the connection will be dropped.

Faelin
  • 41