SSH client does not offer public key to SSH server

There are two things I would check.

1. It appears you are using different ssh keys so make sure the permissions are correct. .ssh folder should be 0700, rsa private key should be 0600, public key should be 0644. Use ls -l ~/.ssh to see permissions.

2. Make sure the public key is transferred to the 2nd server. You can use ssh-copy-id ~/.ssh/SD.pub to copy the public key to the 2nd server. After it runs you can verify it's there by logging in to the server (as root or using a password) and then cat ~/.ssh/authorized_keys It should have the exact output of cat ~/.ssh/SD.pub on your local system. It may have other keys if you added them before.

If both of those things look good and you still can't get in then you should look at the server logs in /var/log/secure or you can also run a 2nd ssh server in the foreground to view what's happening. On the remote server run

sudo $(which sshd) -p 6666 -D -d

Then on your system try to log into the new ssh daemon with

ssh -p 6666 -i ~/.ssh/SD <SERVER>

You should see log information printed out in the terminal on the server which might have more information for why the login is failing.

As an explanation to the 2nd sshd daemon. You need sudo even though the permissions are usually 0755 for security. You also need to provide the full path to the sshd binary. That is why $(which sshd) is included in the command. -p 6666 sets the port (I just picked one at random). -D will run in the foreground and -d enables debugging.

Why doesn't SSH client in second case offer the public key?

The public key is offered by the client if it exists (i.e. file exists and is in the same folder as the private key with the same named + ".pub").

This is a mandatory step in key-based authentication, isn't it?

No, offering the public key is optional. Only proving that the client owns the private key is mandatory.
More explanation can be found here: https://security.stackexchange.com/a/152638

To illustrated both cases:

1. Offering public key, then proving client has private key

debug1: Authentications that can continue: publickey,password
debug1: Offering public key: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM '.ssh/id_rsa'
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: sign_and_send_pubkey: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).

2. Only proving client has private key

debug1: Authentications that can continue: publickey,password
debug1: Trying private key: '.ssh/id_rsa'
debug3: sign_and_send_pubkey: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).

Note that if a public key named .ssh/SD.pub exists and IS NOT related to the private key .ssh/SD (because of a previous key generation for instance), connection will fail. According to the log provided by the OP, this is not the case here, but this is the problem I had when reaching this question. In that case, the log is as follows at client side (and not explicit about why auth failed):

debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:p5eJ+CJ1aRR9xeEcQUDCkbnQ3VUxa8cxjlWUhsYfla4 '.ssh/id_rsa'
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password