Skip to content

Support authentication passthrough to proxy client

The nosshtradamus proxy is currently hard-coded to authenticate to the target server with no SSH key support, a blank password, and blank responses to keyboard-interactive challenges (with a no-challenge pseudo keyboard-interactive flow used to "authenticate" the client to the proxy). While this behavior is sufficient for internal uses, to be usable by anyone else, the proxy should support the full trio of authentication methods when connecting to the target server.

The authentication flow to the target server is already partly integrated with the authentication flow of the client to the proxy; specifically to allow capturing the username provided by the client for passthrough to the target server. The client also does enter a keyboard-interactive authentication flow, which can be used to collect more information from the user to augment the handshake between the proxy and the target server.

Since the proxy will be handling plaintext credentials (and passing them to the target server), it should respect known host keys and strict host key checking configuration.

For a target server supporting key-based, keyboard-interactive, and password authentication, the methods are typically tried in the order just specified. Thus, to support authentication passthrough, the following flow design should be followed:

  • Add -o UserKnownHostsFile=<path> and -o StrictHostKeyChecking=<yes/no> command line arguments to the proxy with same behavior as OpenSSH's ssh client. Default to $HOME/.ssh/known_hosts. Unless StrictHostKeyChecking is disabled, the UserKnownHostsFile should be parsed, and the key for the target should be compared/validated at connection time.
  • Add the -A command line argument to the proxy, with similar meaning to OpenSSH's ssh client. When provided, this will forward the user's SSH agent to the target server via the proxy. Same security caveats apply to agent forwarding through the proxy as a direct connection.
  • Add the -i <identity-file-path> command line argument to the proxy. If provided once with /dev/null, this should disable identity file functionality of the proxy. If provided one or more times with file paths to SSH identity private keys, the proxy may attempt to utilize them when authenticating with the target server. Default is the set of: $HOME/.ssh/id_ed25519 and $HOME/.ssh/id_rsa (intentionally not supporting id_dsa or id_ecdsa keys).

Authentication to the target server proceeds in multiple phases:

  • When the client connects to the proxy, it should default to connecting with agent forwarding enabled (i.e. invoked with ssh -A <proxy>, independent of if nosshtradamus is invoked with -A). The public keys offered by the client agent will be offered as authentication keys to the target server for key-based authentication. If any agent provided key is accepted by the target server, the authentication process will complete.
  • If no agent offered keys are acceptable to the target server (or if the client connected to the proxy without offering agent forwarding), the proxy should iterate over available identity files. If the target server accepts any of the public keys, the proxy will attempt to load the private key from the identity file and use it to authenticate. Private keys may be password protected, so the proxy will prompt the user for the key password (via injected synthetic keyboard-interactive challenge). If any identity file key is accepted by the target server and the proxy succeeds in utilizing that key, the authentication process will complete.
  • If no key was acceptable by the target server (or none were available to the proxy), the proxy will begin keyboard-interactive challenges with the target server. These challenges should be passed through to the client until the target server either completes authentication successfully of the proxy, or provides no more challenges (failure).
  • If the server supports password authentication (the old protocol method, rather than passwords entered as keyboard-interactive challenges), the proxy should translate the password authentication request into a keyboard-interactive challenge sent to the client.
  • If all authentication methods have been exhausted between the proxy and the target server without success, the proxy should notify the client of this situation and then terminate the connection to the client.

With these changes, it should be possible to connect to nearly every target SSH server via the proxy. It should also be possible to write a shell script that wraps an invocation of nosshtradamus and ssh into one command that connects to a target server through a localhost proxy.