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.
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
You have `PubkeyAuthentication` and `PasswordAuthentication` both set to `yes`, which is confusing to me. I thought you were saying they were disabled.
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 serveradmin@50.116.13.30 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).
I guess what you actually did was not disable authentication methods, but enable empty passwords, and set the account to an empty password -- and SSH does not even ask for the empty password in this case or even call it the same name as password auth in the logs. I guess!?
Having both set to yes means you are able to use either. Earlier I mentioned there was the possibility to disable both of them at which point nobody would be able to log in because only keys and passwords are used on that system. That is why I jokingly said you may as well shut down the daemon to save ram. There are methods other than keys and passwords but I have not implemented any of them.
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.
There is no password hash after the first colon in the shadow entry. This was accomplished with
usermod -p '' serveradmin
Using -i pass a key file but since I have not added any of your keys to the system then any key you specify will not match and the client will proceed on to the next authentication method you have enabled and have not explicitly disabled in the client. To accept any random key would require a change to the source code of OpenSSH. One can even hard code a public key into OpenSSH in the source code which I have done when configuring OpenSSH as a recovery daemon that does not read or write to the disk.
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]
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.