AllowUsers [email protected].*.*

Yes one can disable any/all forms of authentication. At that point it might be worth shutting down the SSH daemon to save a few MB of ram. If you mean permit null passwords that can be enabled too.

> At that point it might be worth shutting down the SSH daemon

Could be useful with ForceCommand. Sometimes you really only want to authenticate the server -- like with HTTPS.

  Match Group                     sftpusers
    PubkeyAuthentication            yes
    PasswordAuthentication          yes
    PermitEmptyPasswords            yes
    GatewayPorts                    no
    ChrootDirectory                 /data/sftphome/%u
    ForceCommand                    internal-sftp -l DEBUG1 -f AUTHPRIV -P symlink,hardlink,fsync,rmdir,remove,rename,posix-rename
    AllowTcpForwarding              no
    AllowAgentForwarding            no

When I connect without a `-i` parameter the SSH client attempts to authenticate with all my keys, succeeding with none, then succeeds with authentication type `none`. When I specify -i `/dev/null` the logs are confusing as to what's happening:

    $ ssh -i /dev/null -v [email protected] 2>&1 | egrep -ie 'auth|attempt'
    debug1: Authenticating to 50.116.13.30:22 as 'serveradmin'
    debug1: Will attempt key: /dev/null  explicit
    debug1: Authentication succeeded (none).
    Authenticated to 50.116.13.30 ([50.116.13.30]:22).

A null password is using none [1] which is a reserved term and has specific implications. In this case of passwords, none will succeed since I enabled null passwords and that account has no password set. So none is matching in the PasswordAuthentication option.

  /etc/passwd  serveradmin:x:22218:5000::/data/sftphome/serveradmin:/bin/false
  /etc/shadow  serveradmin::18955:0:99999:7:::

  usermod -p '' serveradmin

I hope that helps this make sense. It is understandable that this is confusing because what I am doing is the opposite of what people are instructed to do. Null passwords are considered a security risk unless you do it intentionally for some unorthodox implementation reason which I have done. I have a cron job that adds accounts within some character restrictions that bots try to brute force. I then monitor the bots behavior to see what current bots are attempting over SSH. I do the same for http/https. Both are what is referred to as a low-interaction honeypot.

Here is a bot with IP and port redacted that just tried to use my server as a DNS proxy:

  Connection from 8.37.x.x port x on 50.116.13.30 port 22
  Accepted password for admin from 8.37.x.x port x ssh2
  Changed root directory to "/data/sftphome/admin" [postauth]
  refused local port forward: originator 127.0.0.1 port x,  target 1.1.1.1 port 53 [postauth]
  Received disconnect from 8.37.x.x port x:11: Disconnected on user's request. [postauth]