Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow different keys for different users #17

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

matyasselmeci
Copy link
Contributor

Allow having multiple keys for bosco (one for each user)
(SOFTWARE-4570)

@matyasselmeci matyasselmeci marked this pull request as draft May 7, 2021 17:34
Copy link
Member

@brianhlin brianhlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far so good but there are some things that need to be thought through wrt rootly SSH


cat <<EOF > /etc/ssh/ssh_config
Host $remote_fqdn
Port $remote_port
IdentityFile ${BOSCO_KEY}
IdentityFile "$(get_bosco_key "root")"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are users going to have to create their secret with a root user and corresponding key?

I think we may be able to drop this rootly SSH config as long as we:

  1. Run remote OS detection using one of the other users
  2. Set up the hacky bosco_key.rsa per user
  3. Run bosco_cluster and env file rsync as the unpriv users

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am totally open to using one of the other users instead of root for this.
Doesn't bosco_cluster have to be run once per user anyway?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but we currently run it as root, not as the unpriv user

for ruser in $users; do
echo "Installing remote Bosco installation for ${ruser}@$remote_fqdn"
[[ $SKIP_WN_INSTALL == 'no' ]] && setup_endpoints_ini "${remote_os_ver%%.*}"
# $REMOTE_BATCH needs to be specified in the environment
bosco_cluster "${bosco_cluster_opts[@]}" -a "${ruser}@$remote_fqdn" "$REMOTE_BATCH"

Keys will be looked for in the following order:
- `/etc/osg/boscokeys/${ruser}@${rhost}.key`
- `/etc/osg/boscokeys/${ruser}.key`
- `/etc/osg/bosco.key`
Keys will be looked for in the following order:
- `/etc/osg/boscokeys/${ruser}.key`
- `/etc/osg/bosco.key`
Copy link
Member

@brianhlin brianhlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pre-approving but like you said, we should test this (both multi and single SSH key setups) before merging

Comment on lines +134 to 140
# HACK: Copy the Bosco key to the location expected by
# bosco_cluster so it doesn't go and try to generate a new one
root_ssh_dir=/root/.ssh/
mkdir -p $root_ssh_dir
chmod 700 $root_ssh_dir
ln -s $BOSCO_KEY $root_ssh_dir/bosco_key.rsa
install -o root -g root -m 0600 "$firstuser_key" $root_ssh_dir/bosco_key.rsa

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we get rid of this if we're not using root for SSH anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd have to check what bosco_cluster does, to see if the hack mentioned in the comment is still needed. root is still the one running the ssh command, it's just using someone else's key.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd have to check what bosco_cluster does, to see if the hack mentioned in the comment is still needed.

I think we want to run bosco_cluster as the unpriv users so that it picks up each of their SSH configs/keys

root is still the one running the ssh command, it's just using someone else's key.

Ah right

@matyasselmeci
Copy link
Contributor Author

Do we still want this? It's kinda stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants