Banner from backend OpenSSH server is not showing up through proxy

[jprorama]

Hi, we use a group mechanism to deny users access to an upstream server if their account is on hold (or some other status condition). We put the user in the appropriate group and then configure opensshd to issue a banner message to that group and deny that group login access. This informs them of the condition on their account.

When we route through the ssh piper proxy that banner message is no longer displayed, although they are successfully denied access.

According to the sshd_config man page, the Banner is displayed before authentication is allowed.

       Banner  The contents of the specified file are sent to the remote user before authentication is allowed.  If  the  argu‐
               ment is none then no banner is displayed.  By default, no banner is displayed.

I suspect that may be the source of our problem. That is, the connection being made from the proxy to the upstream may explicitly already be in the "authentication attempt" phase. Given we have a DenyGroup that may be the only configuration that applies to the connection between piper and the upstream.

I'm not fully versed in the ssh protocol, so may not understand the documentation correctly.

Here is our configuration stanza in OpenSSH.

DenyGroups hold
Match Group hold
  Banner /etc/ssh/hold-msg
  ForceCommand echo
  PasswordAuthentication no

Is there a setting in sshpiper that would facilitate passing this banner to the user?

[diedpigs]

We ran ssh -vvv directly to the upstream server and see our custom message occur prior to authentication

debug1: SSH2_MSG_EXT_INFO received
debug3: kex_input_ext_info: extension server-sig-algs
debug1: kex_ext_info_client_parse: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 53
debug3: input_userauth_banner: entering
Your account is currently on hold.
Please contact us at [email protected] to resolve this issue.
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey

When we try to ssh -vvv to sshpiper server connecting to the same upstream server, the message from upstream does not show up in the console. Compare to the above connection, we do not see receive packet: type 53 while connecting via sshpiper.

debug1: SSH2_MSG_EXT_INFO received
debug3: kex_input_ext_info: extension server-sig-algs
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: password,publickey
debug3: start over, passed a different list password,publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey

[tg123]

i believe the reason is that sshpiper will not proxy anything unless a successful auth handshake with upstream

it is an interesting issue

[tg123]

this is impossible at the moment, sshpiper does not proxy upstream banner message to downstream.

workaround: a tricky plugin

		CreateConfig: func(_ *cli.Context) (*libplugin.SshPiperPluginConfig, error) {

			bannersent := make(map[string]bool)

			return &libplugin.SshPiperPluginConfig{

				PipeCreateErrorCallback: func(remoteAddr string, err error) {
					log.Printf("clean up %v", remoteAddr)
					delete(bannersent, remoteAddr)
				},

				KeyboardInteractiveCallback: func(conn libplugin.ConnMetadata, client libplugin.KeyboardInteractiveChallenge) (*libplugin.Upstream, error) {

					if conn.User() == "mallory" {

						if !bannersent[conn.RemoteAddr()] {
							client("", fmt.Sprintf("you are banned %v", conn.User()), "", false)
							bannersent[conn.RemoteAddr()] = true
						}

						return nil, fmt.Errorf("user banned")
					}

					_, _ = client("", fmt.Sprintf("Welcome, %v", conn.User()), "", false)

					return &libplugin.Upstream{
						Auth: libplugin.CreateNextPluginAuth(map[string]string{}),
					}, nil
				},
			}, nil
		},

long run:

• go ssh introduced PreAuthConnCallback last month, sshpiper should adopt it and expose api to plugins
• double checked https://www.rfc-editor.org/rfc/rfc4252#section-5.4, sshpiper can technically proxy those messages during auth and should do it