“none” authentication error regarding publickey

[Joshua1909]

SSH-MITM Version

3.0.2

Platform detail

Kali Linux 6.0.0

Arguments used to start SSH-MITM

ssh-mitm server --enable-none-auth

SSH client used

putty, ssh on Linux

SSH server used

Openssh 9.0p1

What steps will reproduce the bug?

When using ssh-mitm to intercept a "none" authentication, the server provides an error "ssh agent not forwarded. Login to remote host not possible with publickey authentication.” My ssh server configuration works with none authentication, so if I ssh directly then “none” works. It seems as though the —enable-none-auth is not being carried to the backend ssh session.

What should have happened?

An ssh session would have been established to a local ssh server where “none” authentication is allowed.

Additional information

I’ve also tried: “—enable-none-auth and —disable-publickey-auth” in combination

[manfred-kaiser]

Thanks for the bug report.

At the moment SSH-MITM has only full support for "publickey" AND "password" authentication. This means, the server must provide both authentication methods.

For example, if the server only supports "publickey" but does not provide "password" authentication, SSH-MITM still asks the user for the password in cases when authentication with "publickey" is not possible.

SSH-MITM was created to test if the client is vulnerable to spoofing FIDO tokens and to prove if it's possible to intercept the authentication process (mainly publickey auth). See https://docs.ssh-mitm.at/user_guide/trivialauth.html and https://www.openssh.com/agent-restrict.html

"none" authentication was added to SSH-MITM, because it can be used to spoof FIDO tokens. With "none" authentication, the client can be forced to login and does not trigger the FIDO token. "none" authentication has some drawbacks, because SSH-MITM was not able to learn something about the authentication process and this missing knowledge can result in failed login attemps. The argument "--enable-none-auth" was only added to test this behavior.

During a full man in the middle attack, SSH-MITM should respect the servers authentication methods, but at the moment, this is not implemented.

With "keyboard-interactive" it's the same as with "none" authentication. "keyboard-interactive" was only added to prove that spoofing FIDO tokens is possible, but SSH-MITM does not have support for intercepting the authentication process in cases when "keyboard-interactive" is used.

The error "ssh agent not forwarded. Login to remote host not possible with publickey authentication.” is a side effect of "none" authentication. Because you are using "none" authentication, SSH-MITM does not know anything about the authentication process and tires to login with publickey authentication (a side effect, which comes from the tests to spoof FIDO tokens)

Intercepting public key authentication requires a forwarded agent and if SSH-MITM does not got the agent the connection is closed with the mentioned error. This can be avoided to provide a fallback host (e.g. a honeypot)

I have plans to add full support to intercept the authentication process, but this requires some major changes which takes a lot of time.

At the moment I'm the only developer which is actively working on SSH-MITM, but I would be glad to get some help 😉

[Joshua1909]

Thanks so much for taking the time to reply. I appreciate the context and detailed answer, that makes a lot of sense in regards to the behaviour I saw. I may take a look and see if it's a feature I can work on.