28 ms·
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 a
by LinuxBender 5y ago
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.
/etc/passwd serveradmin:x:22218:5000::/data/sftphome/serveradmin:/bin/false
/etc/shadow serveradmin::18955:0:99999:7:::
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]
[1] - https://datatracker.ietf.org/doc/html/rfc4252#page-7 https://datatracker.ietf.org/doc/html/rfc4252#page-7