provide user with option to enable password ssh after the fact
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
awstrial |
Triaged
|
Medium
|
Scott Moser |
Bug Description
There are 2 cases where the user might want to enable password ssh connections
a.) they do not have ssh keys [we're not supporting this now]
b.) they've lost the ssh private keys paired with their ssh keys in launchpad.
This bug is for 'b'.
Because the instances are launched with a ssh key that is known to the launcher, it *can* ssh to the instance and fix it.
I've got the following script htat could be run remotely to do this:
#!/bin/sh
user=${1}; newpw=${2}
fail() { echo "$@" 1>&2; exit 1; }
pa_s="\
echo "${user}:${newpw}" | chpasswd ||
fail "failed to chpasswd for ${user}"
sed -i "s,${pa_
fail "failed to switch chpasswd for ${user}"
passwd --expire "${user}" ||
fail "failed to expire password for ${user}"
restart ssh ||
fail "failed to restart ssh"
Changed in awstrial: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in awstrial: | |
assignee: | nobody → Scott Moser (smoser) |
We had initially decided to "fix" this by having a password set in the instance for all instances, and storing that password and showing it to the user only when they needed it.
The idea was also to expire the password as that plaintext password would be in the metadata service. Over all, we didn't like the idea of enabling password auth by default, and it is no "sneakier" (we're not being sneaky) to have an additional set of keys loaded into the instance.
Expiring the password cannot work as then the ssh key authed user is prompted for the old password (which they do not know).
We kind of concluded that the best way to deal with this is ssh via key, and set pasword that way.