30 ms·
I'd argue that if you're setting the same password on thousands of servers, what you're doing is inherently insecure.
by david_shaw 11y ago
I'd argue that if you're setting the same password on thousands of servers, what you're doing is inherently insecure.
- deleted 11y ago[deleted]
- seletskiy 11y agoIt depends. You can have many development servers/nodes, which are infrastructurally "inside" the company and is not accessible from outside. They should be managed somehow, security requirements can be considerably less than at production cluster, and as an example it's always good to have rescue password for the ops team that can be used to login to the server in case of it's unresponsible in any other way. Also, shadowd do not make assumption about same password distribution, it can handle any amount of passwords by your choice, depending on severity and importance of service.
- brazzledazzle 11y agoI think Google is on the right track with assuming that there is no perimeter and it will only be a matter of time before every company of any decent size/budget will follow suit (maybe within the next 3-7 years). The network security architecture that can best be described as a hard shell with a squishy inside has been proven time and again to be dangerously full of assumptions.
- atmosx 11y agoSeriously, I can't imagine this scenario in real life without ssh-keys.
- seletskiy 11y agoshadowd is not against SSH keys in any way. It can serve them as well. The main point is always having password access for cruicial services, so any given ops engineer can login from almost everywhere. In real life there can be different situations, anecdotal, but at some point of time I have to fix problem via SSH shell from my mobile phone.