2 clarify
source | link

ssh keys and login-passwords are stored in separate locations on virtually any Unix-like system. There's no reason why (aside from 30 years of history preceding ssh) the two couldn't have used the same storage. But what we have now is separate, with scattered attempts to store the collection of credentials in key-managers.

Typically a user's ssh information is in $HOME/.ssh, while the logon information is in /etc/passwd, /etc/shadow/, /etc/group and /etc/gshadow.

A key manager could combine those, by providing passwords (or the analogous information) as needed. But that's the exception rather than the rule.

Not to recommend it one way or the other, I worked with SnareWorks a while back. If you google on that, it appeared on the scene around 2000. That collected the credentials for various applications (or remote systems) and associated the collection with a user.

ssh keys and login-passwords are stored in separate locations on virtually any Unix-like system. There's no reason why (aside from 30 years of history preceding ssh) the two couldn't have used the same storage. But what we have now is separate, with scattered attempts to store the collection of credentials in key-managers.

Typically a user's ssh information is in $HOME/.ssh, while the logon information is in /etc/passwd, /etc/shadow/, /etc/group and /etc/gshadow.

A key manager could combine those, by providing passwords (or the analogous information) as needed. But that's the exception rather than the rule.

ssh keys and login-passwords are stored in separate locations on virtually any Unix-like system. There's no reason why (aside from 30 years of history preceding ssh) the two couldn't have used the same storage. But what we have now is separate, with scattered attempts to store the collection of credentials in key-managers.

Typically a user's ssh information is in $HOME/.ssh, while the logon information is in /etc/passwd, /etc/shadow/, /etc/group and /etc/gshadow.

A key manager could combine those, by providing passwords (or the analogous information) as needed. But that's the exception rather than the rule.

Not to recommend it one way or the other, I worked with SnareWorks a while back. If you google on that, it appeared on the scene around 2000. That collected the credentials for various applications (or remote systems) and associated the collection with a user.

1
source | link

ssh keys and login-passwords are stored in separate locations on virtually any Unix-like system. There's no reason why (aside from 30 years of history preceding ssh) the two couldn't have used the same storage. But what we have now is separate, with scattered attempts to store the collection of credentials in key-managers.

Typically a user's ssh information is in $HOME/.ssh, while the logon information is in /etc/passwd, /etc/shadow/, /etc/group and /etc/gshadow.

A key manager could combine those, by providing passwords (or the analogous information) as needed. But that's the exception rather than the rule.