3 ms·
One mitigation against this is to specify on the target hosts where that keys are valid from. One could even be as liberal as to give the entire CIDR block of
by LinuxBender 5y ago
One mitigation against this is to specify on the target hosts where that keys are valid from. One could even be as liberal as to give the entire CIDR block of their ISP or Corporate IP CIDR block or preferably use a VPN network. The key will not be valid for anyone not in the specified networks or IP's separated by commas.
e.g. using my tinc VPN mesh
grep keys /etc/ssh/sshd_config
AuthorizedKeysFile /etc/ssh/keys/%u
cat /etc/ssh/keys/root # honeypot server
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
I would be happy to provide my private key and a VM IP if anyone would like to try this out.
- xyzzyz 5y agoIf you think this is secure even if you leak private key, why not just disable key checking altogether and just allow anyone to log in if they come from accepted network?
- LinuxBender 5y agoOne could do that as well. Different use cases can mix and match any restrictions using the Match block in sshd_config or simply having a general restriction like this. AllowUsers root@192.168.*.*
- Taek 5y agoDefense in depth - have several independent layers of security so you have some breathing room to fix things if one of the layers is fully compromised.
- DarylZero 5y agoDoes OpenSSH let you disable all authentication?
- LinuxBender 5y agoDoes OpenSSH let you disable all authentication? 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.
- DarylZero 5y agoHuh. Neat. > 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.
- LinuxBender 5y agoGood point. That is what I am doing: 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
- DarylZero 5y agoYou 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!?