4 ms·

If you mean that the problem is that they have the same salt, then just call "passwd" individually on each instead of copying /etc/shadow. But anyway, just dis

by devit 11y ago

If you mean that the problem is that they have the same salt, then just call "passwd" individually on each instead of copying /etc/shadow. But anyway, just disable passwords and login with SSH public key authentication.

seletskiy 11y ago
Calling passwd on each host (imagine hundred of them for tens of users) and manually setting same password is not the way to go. The idea is to have same password will be setted up on numerous amount of nodes without storing or transferring it. SSH keys are good, but there are always should be rescue password which can be entered via IPMI or by physically attaching to the server. Also, `sudo` password (which is also handled by /etc/shadow) is a good measure on production servers and should be set somehow. shadowd resolves it.
- brazzledazzle 11y ago
  >rescue password which can be entered via IPMI or by physically attaching to the server. If it's an emergency you can reboot into a single user/recovery/rescue state and reset it. No need to increase the attack surface just for that. >Also, `sudo` password (which is also handled by /etc/shadow) is a good measure on production servers and should be set somehow. I agree about a sudo password being a good idea, but if we're talking about the "right" way I'd say a authentication directory backend of some sort would be better suited for that.
  - seletskiy 11y ago
    Often, the only way to know what's wrong with server/software is to login through IPMI and see it while it's still alive. Reboot will lost that information. Don't see exactly how enabling root password login at physical/IMPI console will increase attack surface (not SSH). Regarding authentication backend I've already tried to address that vision. Unable to become root when auth backend offline/unreachable/misconfigured is significantly worse than having local shadow which is always works.
    - brazzledazzle 11y ago
      The chance of your central authentication system being down at the same time you have to troubleshoot an issue with a live system seems unlikely. And for those rare cases you can just enable the account in single user and troubleshoot after the reboot.
- VLM 11y ago
  > manually setting same password is not the way to go Agreed, if you have something like dish installed, something like dish "echo root:password | chpasswd" should do the trick to everything dish knows about. This is a simplification, but the general idea isn't too far off. If you don't know why its a simplification, then doing it this exact way is probably a bad idea.
  - seletskiy 11y ago
    I'll call it oversimplification. It very error-prone and very difficult to automate. Of course, you can always tell your ops engineer to run something like `xargs -n1 -I{} ssh {} echo ... \| chpasswd < hosts.list` manually, but we are talking about automatisation of routine tasks, not "solving" them by shell scripts.

by devit 11y ago

seletskiy 11y ago

Calling passwd on each host (imagine hundred of them for tens of users) and manually setting same password is not the way to go. The idea is to have same password will be setted up on numerous amount of nodes without storing or transferring it. SSH keys are good, but there are always should be rescue password which can be entered via IPMI or by physically attaching to the server. Also, `sudo` password (which is also handled by /etc/shadow) is a good measure on production servers and should be set somehow. shadowd resolves it.

brazzledazzle 11y ago
>rescue password which can be entered via IPMI or by physically attaching to the server. If it's an emergency you can reboot into a single user/recovery/rescue state and reset it. No need to increase the attack surface just for that. >Also, `sudo` password (which is also handled by /etc/shadow) is a good measure on production servers and should be set somehow. I agree about a sudo password being a good idea, but if we're talking about the "right" way I'd say a authentication directory backend of some sort would be better suited for that.
- seletskiy 11y ago
  Often, the only way to know what's wrong with server/software is to login through IPMI and see it while it's still alive. Reboot will lost that information. Don't see exactly how enabling root password login at physical/IMPI console will increase attack surface (not SSH). Regarding authentication backend I've already tried to address that vision. Unable to become root when auth backend offline/unreachable/misconfigured is significantly worse than having local shadow which is always works.
  - brazzledazzle 11y ago
    The chance of your central authentication system being down at the same time you have to troubleshoot an issue with a live system seems unlikely. And for those rare cases you can just enable the account in single user and troubleshoot after the reboot.
VLM 11y ago
> manually setting same password is not the way to go Agreed, if you have something like dish installed, something like dish "echo root:password | chpasswd" should do the trick to everything dish knows about. This is a simplification, but the general idea isn't too far off. If you don't know why its a simplification, then doing it this exact way is probably a bad idea.
- seletskiy 11y ago
  I'll call it oversimplification. It very error-prone and very difficult to automate. Of course, you can always tell your ops engineer to run something like `xargs -n1 -I{} ssh {} echo ... \| chpasswd < hosts.list` manually, but we are talking about automatisation of routine tasks, not "solving" them by shell scripts.