Note: In the second part of the email I will explain how I came across to this problem, namely through gitolite. But the issue is an ssh issue rather than a gitolite issue. Still, I added the gitolite tag in case someone has an ad hoc solution for the specific case.
Here's the general problem.
I have a server with two users, alice and bob. alice can assume bob identity via su - bob, but she does not know bob's password (for whatever reason). From her laptop Alice would like to ssh into the server as bob, but she can't since she hasn't his password. Is there a way to exploit her ability to assume bob's identity to mimic the behavior of ssh bob@server? In a way, I would like to tunnel the ssh connection through a change of user identity. I think this is a long shot, I'm guessing ssh does not allow this. But I figured I'd ask anyways.
Where does the problem come from: gitolite
I am trying to use gitolite. I got the server administrator to set up the gitolite user and he gave me the power to do su - gitolite on the server. However, he did not give me gitolite's password, and given the time of the day, the server admin has gone home, so I have to wait till tomorrow to ask him that password. Meanwhile, I would like to find a workaround (if possible), just for fun.
Brief gitolite-ssh interaction recap (as far as I understand): the authorized_keys file in gitolite/.ssh has lines like this
# gitolite start
command="/usr/share/gitolite3/gitolite-shell some_user_name",no-portforwarding,
no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa SOME_USER_NAME_KEY
# gitolite end
So the whole gitolite machinery is activated when an authorized key tries to ssh into gitolite's account. In fact, when an authorized key sshs (how do you conjugate the verb 'to ssh'?!?) into gitolite's account, gitolite-shell is executed and takes over, allowing only git related commands. You may ask "then why do you need gitolite's password if you are one of its authorized keys? Glad you asked. In order for some_user_name to modify the configuration of gitolite, it is not enough to add a line like those to ~gitolite/.ssh/authorized_keys; some_user_name needs to be added to gitolite's configuration file, which is stored inside the git repository in ~gitolite/repository/gitolite-admin.git. In order to change this config file, one has to clone that repo, modify the config file, and push the repo back. The catch: the users allowed to push modifications in the gitolite-admin repo are listed in the gitolite-admin repo itself... At the beginning, the user that initialized gitolite (in this case, the user gitolite) is the only one listed in such config file. So I need to be able to access that conf file as gitolite, in order to add my user among the users that can change the configurations. Once I do that, I can forget about the user gitolite and administer the gitolite repositories as myself.
Is there a way to exploit her ability to assume bob's identity to mimic the behavior of ssh bob@server?
Sure: if Alice can open a shell session as bob (with su - bob), she can:
/home/bob/.ssh, /home/alice/.ssh/id_rsa.bob.pub and id_rsa.bob.bob with ssh -i /home/alice/.ssh/id_rsa.bob bob@server (or use an .ssh/config file)Don't forget to read:
Reminder: any use of gitolite is always done through the git or gitolite user, never as 'alice' or 'bob'.