e.g. using my tinc VPN mesh

  grep keys /etc/ssh/sshd_config
  AuthorizedKeysFile          /etc/ssh/keys/%u

  from="192.168.0.0/16,10.15.10.2" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDDlyvd+LAveSiIIgQW3Y+aWsb8bTu70tgXQjoWMrMAbKt1/sDoE/w2qqLBSqLjJmA46zKqwgZhnO8hkZjpizjb909fNYrgyNOsRcHOvumanORUGjcumxi5fklqNZCXC1rehX4z+tnVzygtDNQcqlmyy1ElBM+SxKS+YIrOymPOU6bc5V1sildq5cVUSuEHcLggOadCj6azbiR1J46D6UYxAaKYjq2OloLZXRhvSYrmVeH+PNKiShgYBu4TfCg4UoJKZsHTaeS2akZAQTqcjy7bB8HRWGXYEMKAKA95w8MTqaWlIoMKBuOJnd8+wRXrZKnSsTQmQQZg0rggO6GC8ufT leaked_on_purpose

  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]

I've never understood this.

But there are also niche situations where an attacker has read permissions for files but not memory. It's atypical, but in cases where you have 'confused deputies' it happens - for example, if I have a service that attempts to safely broker reads to files but that service has a logic bug where a client can trick it into reading sensitive files.

The classic example of this is a path traversal in a web service.

Also, while there's no boundary, attackers are a lot happier reading files than memory. They're only human.

In general I find that, when you can, you should just encrypt your data. It can protect you in some surprising ways.

Yes, true one-time pad encryption is not secure by modern standards, as you mention there's no authentication, you need a perfect random number source, and key management is horrendous.

However, the concept of encryption by XORing a stream and the plaintext is very much the modern way of doing things, and "OTP" is an analogy for that.