Second, the target system account must be configured to be passwordless. Passwordless accounts are commonly used for accounts that use certificate-based authentication.
not true. regardless if all your user accounts are using key based auth or not, some system accounts will always be passwordless, because they are not supposed to be logged into.
“passwordless” here means that the account doesn’t have a password. What the person you’re replying to means is that password authentication should be completely disabled in the SSH config, as that’s the only way to exploit this issue.
But passwords need to be enabled for SSH. You must submit a faulty password of a specific kind, and the SSH server misinterprets it for passwordless accounts, which means the server must be configured to allow you to attempt a password.
When logging into a passwordless account, the attacker can gain access by inputting more than 256 characters in the password field.
If you disable passwords in SSH, there is no password field. There is no way for you to input anything. The connection will just be refused as the only auth method is an ssh key. If there is no matching key, SSH will refuse the connection.
If you don’t do that, the daemon will fall back to a password, which might then be vulnerable. However, no sane administrator would leave password auth enabled. Usually, you use the SSH password once - to copy an SSH key on the system. Then you disable it.
If you have to support the sort of user that barely managed to download a copy of putty a few years ago and kept using this, then walking them through key generation and use is a nightmare.
One could fairly argue that maybe such people shouldn’t have access to a system, but it is a reality.
Of course the likelihood that a system using musl is something that class of user would be accessing is lower.
Maybe now that ssh is generally “just there” for Windows users, you can more easily work with them to generate a key, or give them a zip file to make them have a key in a standard way. But the interaction of ssh and windows file security can be… Interesting, though mostly an issue on the ash server side.
Yeah, issue being if they work for your company and management insists they have a job to do and you must provide what they ask for to do their job.
Though the most recent guy to inflict that on me is at risk of pissing off a customer as he pulled that on them and they are complaining rightly that someone that can’t sort out key based ssh auth has zero business touching their sysems. So some people can give reasonable push back.
Given this is a vuln when entering the password, just turn off password auth and use ssh keys only. It’s what you should be doing anyway.
The vuln is specifically for key-based accounts:
not true. regardless if all your user accounts are using key based auth or not, some system accounts will always be passwordless, because they are not supposed to be logged into.
“passwordless” here means that the account doesn’t have a password. What the person you’re replying to means is that password authentication should be completely disabled in the SSH config, as that’s the only way to exploit this issue.
But passwords need to be enabled for SSH. You must submit a faulty password of a specific kind, and the SSH server misinterprets it for passwordless accounts, which means the server must be configured to allow you to attempt a password.
If you disable passwords in SSH, there is no password field. There is no way for you to input anything. The connection will just be refused as the only auth method is an ssh key. If there is no matching key, SSH will refuse the connection.
If you don’t do that, the daemon will fall back to a password, which might then be vulnerable. However, no sane administrator would leave password auth enabled. Usually, you use the SSH password once - to copy an SSH key on the system. Then you disable it.
Easier said than done.
If you have to support the sort of user that barely managed to download a copy of putty a few years ago and kept using this, then walking them through key generation and use is a nightmare.
One could fairly argue that maybe such people shouldn’t have access to a system, but it is a reality.
Of course the likelihood that a system using musl is something that class of user would be accessing is lower.
Maybe now that ssh is generally “just there” for Windows users, you can more easily work with them to generate a key, or give them a zip file to make them have a key in a standard way. But the interaction of ssh and windows file security can be… Interesting, though mostly an issue on the ash server side.
More that, such people shouldn’t be allowed to be sysadmins, yet self-host and/or expose any ports to the internet.
Yeah, issue being if they work for your company and management insists they have a job to do and you must provide what they ask for to do their job.
Though the most recent guy to inflict that on me is at risk of pissing off a customer as he pulled that on them and they are complaining rightly that someone that can’t sort out key based ssh auth has zero business touching their sysems. So some people can give reasonable push back.
For added security, there is a pam module for 6-digit OTP