0

I'm entirely confused by this one.

I've got a Docker container that periodically tries to connect to a Git server, and fails. I see the periodic connects in the sshd logs: Aug 09 16:14:01 <server> sshd[11441]: Accepted publickey for <user1> from <docker> port 58968 ssh2. That part is correct, so to troubleshoot further I try to run ssh in verbose mode, from the same Docker container using the same public keys etc.

GIT_TRACE=1 GIT_SSH_COMMAND="ssh -vvvv" git clone ssh://baduser@<server>:/test

To my utter surprise, the ssh client shows that a login attempt for <baduser using publickey is sent to server , but the server logs do not show anything coming from baduser. Yet the client is fairly certain that it's communicating; it's reporting debug3: receive packet: type 51. That's a SSH_MSG_USERAUTH_FAILURE.

Now the ssh client will ask for a password, which won't work and isn't intended. But after entering an empty password, that attempt does show up in the server logs: Failed password for <baduser> from <docker> port 5920.

Clearly one side is wrong here. Either the server is logging only some types of failures but not all, or the client isn't receiving packets when it claims it does. But who is right?

(The tests with baduser are obviously expected to fail; the goal of the experiment was to figure out if the failures with the real user1 were perhaps caused by sshd failing to recognize a valid user account.)

MSalters
  • 700
  • 5
  • 6
  • SSH from Ubuntu 22, SSHD on Debian 8. Server worked in the past with RSA keys, but Ubuntu 22's SSH client doesn't like those. – MSalters Aug 09 '22 at 14:49

1 Answers1

0

Turns out the server logs are incomplete. Adding a baduser account with a proper .ssh/authorized_keys allowed the git clone to succeed, and now the successful login does appear in the logs.

The client was right - the server rejected both publickey and password logins, but logged only the latter.

MSalters
  • 700
  • 5
  • 6