> Finally, we have the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create a git-daemon-export-ok file — the daemon won’t serve a repository without that file in it — but, other than that, there is no security. Either the Git repository is available for everyone to clone, or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access but, given the lack of authentication, anyone on the internet who finds your project’s URL could push to that project. Suffice it to say that this is rare.

Not really a practical answer, as your SSH client doesn't (and shouldn't) offer this, but of course the rest of the SSH protocol just relies on a negotiated arbitrary encryption for moving data between client and server which is transparent to it, you can drop in different algorithms (on most PCs today AES will be the best option because it is hardware accelerated, on cheaper or lower power hardware ChaCha20 may be much better). So, it is technically possible to have a NO-OP encryption layer but just a bad idea.

SSHv2 negotiates this stuff up front, before anybody authenticates anywhere. Key Agreement protocols like Diffie-Hellman allow two parties to agree over the network on keys and encrypt all their data even though they don't yet know who the other party is, and in SSH the encryption protocols just have string names like chacha20-poly1305@openssh.com so you could invent useless-empty@example.com and if anybody wants to agree to use that the consequences are on them.