This fixes #11 in a slightly different manner than originally outlined. Instead of requiring a user to specify that he or she desires password authentication in the aker.ini config, we assume SSH private keys first, and then we automatically fail back to password-based authentication only if SSH key authentication fails.
The reason for the change in implementation is the (admittedly late) realization that SSH keys might be used for some remote systems but not all of them. If, for example, a company is using Aker to manage their Linux servers and myriad network or embedded devices, they might use SSH keys for the Linux servers but passwords for the network and embedded devices. My original suggested implementation would have required separate Aker installations for each use case. This implementation allows them to be combined while gracefully handling failures of SSH key authentication in multiple cases.
This fixes #11 in a slightly different manner than originally outlined. Instead of requiring a user to specify that he or she desires password authentication in the
aker.ini
config, we assume SSH private keys first, and then we automatically fail back to password-based authentication only if SSH key authentication fails.The reason for the change in implementation is the (admittedly late) realization that SSH keys might be used for some remote systems but not all of them. If, for example, a company is using Aker to manage their Linux servers and myriad network or embedded devices, they might use SSH keys for the Linux servers but passwords for the network and embedded devices. My original suggested implementation would have required separate Aker installations for each use case. This implementation allows them to be combined while gracefully handling failures of SSH key authentication in multiple cases.