share ssh session/key with remote user











up vote
5
down vote

favorite
2












Assume the following setup:




  1. User bob is working locally on his workstation foo.

  2. User alice is working locally on her workstation bar.

  3. User bob has ssh access to server baz:22 via a key stored at bob@foo:.ssh/id_rsa.

  4. User alice has ssh access to bob's workstation foo:22 but not to server baz.


Is there a way for bob to ssh to baz sharing his session (via port forwarding?) or key (via ssh-agent forwarding?) such that alice can access baz from bar via foo (assuming bob's identity on foo)?





Addendum:



There are a few mor thinks that I should have clarfied:





  1. bob doesn't want alice to know his password


  2. bob doesn't want alice to be able to run rm -rf /home/bob on foo (on baz however that would be fine obbviously).


As suggested by @mukesh-sai-kumar,
one could have alice login to foo (as bob?) and ssh with the shared key from there.



The best approach I can see so far would be to create a new key-pair for alice on bar, allow the public key on foo and automatically run the ssh bob@baz via the command="ssh [...]" option in the authorized_keys file.



This would allow to setup ssh baz on bar to actually ssh bob@foo using the new key-pair via alice@bar:.ssh/config with the forwarding of bob@foo logins using this specific key to bob@baz via bob@foo:.ssh/authorized_keys (authorizing alice's key but restricting command to the ssh baz call).



This way, the two new constraints would be met and alice wouldn't even see anything as this hypothetical interactive session shows:





[alice@foo:~] (1) $ hostname
foo
[alice@foo:~] (2) $ whoami
alice
[alice@foo:~] (3) $ ssh baz
[bob@baz:~] (1) $ hostname
baz
[bob@baz:~] (2) $ whoami
bob
[bob@baz:~] (3) $ exit
[alice@foo:~] (4) $ hostname
foo
[alice@foo:~] (5) $ whoami
alice
[alice@foo:~] (6) $


The only remaining problem is that bob's ssh key on foo needs to be shared with bob's session initated by the ssh from alice (via ssh-agent?) .










share|improve this question
























  • @JeffSchaller: Thx for the typo fix. :-)
    – mschilli
    Dec 5 at 14:16















up vote
5
down vote

favorite
2












Assume the following setup:




  1. User bob is working locally on his workstation foo.

  2. User alice is working locally on her workstation bar.

  3. User bob has ssh access to server baz:22 via a key stored at bob@foo:.ssh/id_rsa.

  4. User alice has ssh access to bob's workstation foo:22 but not to server baz.


Is there a way for bob to ssh to baz sharing his session (via port forwarding?) or key (via ssh-agent forwarding?) such that alice can access baz from bar via foo (assuming bob's identity on foo)?





Addendum:



There are a few mor thinks that I should have clarfied:





  1. bob doesn't want alice to know his password


  2. bob doesn't want alice to be able to run rm -rf /home/bob on foo (on baz however that would be fine obbviously).


As suggested by @mukesh-sai-kumar,
one could have alice login to foo (as bob?) and ssh with the shared key from there.



The best approach I can see so far would be to create a new key-pair for alice on bar, allow the public key on foo and automatically run the ssh bob@baz via the command="ssh [...]" option in the authorized_keys file.



This would allow to setup ssh baz on bar to actually ssh bob@foo using the new key-pair via alice@bar:.ssh/config with the forwarding of bob@foo logins using this specific key to bob@baz via bob@foo:.ssh/authorized_keys (authorizing alice's key but restricting command to the ssh baz call).



This way, the two new constraints would be met and alice wouldn't even see anything as this hypothetical interactive session shows:





[alice@foo:~] (1) $ hostname
foo
[alice@foo:~] (2) $ whoami
alice
[alice@foo:~] (3) $ ssh baz
[bob@baz:~] (1) $ hostname
baz
[bob@baz:~] (2) $ whoami
bob
[bob@baz:~] (3) $ exit
[alice@foo:~] (4) $ hostname
foo
[alice@foo:~] (5) $ whoami
alice
[alice@foo:~] (6) $


The only remaining problem is that bob's ssh key on foo needs to be shared with bob's session initated by the ssh from alice (via ssh-agent?) .










share|improve this question
























  • @JeffSchaller: Thx for the typo fix. :-)
    – mschilli
    Dec 5 at 14:16













up vote
5
down vote

favorite
2









up vote
5
down vote

favorite
2






2





Assume the following setup:




  1. User bob is working locally on his workstation foo.

  2. User alice is working locally on her workstation bar.

  3. User bob has ssh access to server baz:22 via a key stored at bob@foo:.ssh/id_rsa.

  4. User alice has ssh access to bob's workstation foo:22 but not to server baz.


Is there a way for bob to ssh to baz sharing his session (via port forwarding?) or key (via ssh-agent forwarding?) such that alice can access baz from bar via foo (assuming bob's identity on foo)?





Addendum:



There are a few mor thinks that I should have clarfied:





  1. bob doesn't want alice to know his password


  2. bob doesn't want alice to be able to run rm -rf /home/bob on foo (on baz however that would be fine obbviously).


As suggested by @mukesh-sai-kumar,
one could have alice login to foo (as bob?) and ssh with the shared key from there.



The best approach I can see so far would be to create a new key-pair for alice on bar, allow the public key on foo and automatically run the ssh bob@baz via the command="ssh [...]" option in the authorized_keys file.



This would allow to setup ssh baz on bar to actually ssh bob@foo using the new key-pair via alice@bar:.ssh/config with the forwarding of bob@foo logins using this specific key to bob@baz via bob@foo:.ssh/authorized_keys (authorizing alice's key but restricting command to the ssh baz call).



This way, the two new constraints would be met and alice wouldn't even see anything as this hypothetical interactive session shows:





[alice@foo:~] (1) $ hostname
foo
[alice@foo:~] (2) $ whoami
alice
[alice@foo:~] (3) $ ssh baz
[bob@baz:~] (1) $ hostname
baz
[bob@baz:~] (2) $ whoami
bob
[bob@baz:~] (3) $ exit
[alice@foo:~] (4) $ hostname
foo
[alice@foo:~] (5) $ whoami
alice
[alice@foo:~] (6) $


The only remaining problem is that bob's ssh key on foo needs to be shared with bob's session initated by the ssh from alice (via ssh-agent?) .










share|improve this question















Assume the following setup:




  1. User bob is working locally on his workstation foo.

  2. User alice is working locally on her workstation bar.

  3. User bob has ssh access to server baz:22 via a key stored at bob@foo:.ssh/id_rsa.

  4. User alice has ssh access to bob's workstation foo:22 but not to server baz.


Is there a way for bob to ssh to baz sharing his session (via port forwarding?) or key (via ssh-agent forwarding?) such that alice can access baz from bar via foo (assuming bob's identity on foo)?





Addendum:



There are a few mor thinks that I should have clarfied:





  1. bob doesn't want alice to know his password


  2. bob doesn't want alice to be able to run rm -rf /home/bob on foo (on baz however that would be fine obbviously).


As suggested by @mukesh-sai-kumar,
one could have alice login to foo (as bob?) and ssh with the shared key from there.



The best approach I can see so far would be to create a new key-pair for alice on bar, allow the public key on foo and automatically run the ssh bob@baz via the command="ssh [...]" option in the authorized_keys file.



This would allow to setup ssh baz on bar to actually ssh bob@foo using the new key-pair via alice@bar:.ssh/config with the forwarding of bob@foo logins using this specific key to bob@baz via bob@foo:.ssh/authorized_keys (authorizing alice's key but restricting command to the ssh baz call).



This way, the two new constraints would be met and alice wouldn't even see anything as this hypothetical interactive session shows:





[alice@foo:~] (1) $ hostname
foo
[alice@foo:~] (2) $ whoami
alice
[alice@foo:~] (3) $ ssh baz
[bob@baz:~] (1) $ hostname
baz
[bob@baz:~] (2) $ whoami
bob
[bob@baz:~] (3) $ exit
[alice@foo:~] (4) $ hostname
foo
[alice@foo:~] (5) $ whoami
alice
[alice@foo:~] (6) $


The only remaining problem is that bob's ssh key on foo needs to be shared with bob's session initated by the ssh from alice (via ssh-agent?) .







ssh ssh-tunneling ssh-agent






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 5 at 12:24









Jeff Schaller

37.9k1053123




37.9k1053123










asked Jan 15 at 9:28









mschilli

272111




272111












  • @JeffSchaller: Thx for the typo fix. :-)
    – mschilli
    Dec 5 at 14:16


















  • @JeffSchaller: Thx for the typo fix. :-)
    – mschilli
    Dec 5 at 14:16
















@JeffSchaller: Thx for the typo fix. :-)
– mschilli
Dec 5 at 14:16




@JeffSchaller: Thx for the typo fix. :-)
– mschilli
Dec 5 at 14:16










2 Answers
2






active

oldest

votes

















up vote
2
down vote



accepted










Alice can give Bob her public key, and Bob can add a line to his own .ssh/authorized_keys file that will allow Alice to start a ssh session (as Bob) on Bob's workstation foo. Using the command= option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection to baz as Bob, and using a key locally accessible to Bob on bar.



command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever



Optionally, you can include further constraint options (no-port-forwarding, from=, etc. - see sshd man page section on AUTHORIZED_KEYS FILE FORMAT).



When Alice runs ssh bob@bar and authenticates with her private key, she will be connected through bar to a ssh session on baz, without having any control over the intermediate session on Bob's workstation.



Note that from the perspective of baz (logging, security audit), there is no distinction between this tunneled connection initiated by Alice, and a "normal" connection by Bob from his own workstation. This may be what you asked for, but not what you want.



For making the protected key available to Alice for her session, you can explicitly set the environment variable SSH_AUTH_SOCK to be the path that Bob uses for his session (change the authorized_keys entry to command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...) To avoid having to update the path when it changes (logoff/login typically), Bob can run a dedicated agent on Alice's behalf with an explicit path specified (ssh-agent -a ~/.ssh/agent_for_alice and add only the specific key with SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa and entering the passphrase.






share|improve this answer























  • Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
    – mschilli
    Jan 17 at 14:08






  • 1




    Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
    – PKapp
    Jan 18 at 2:30










  • Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
    – mschilli
    Jan 18 at 9:34




















up vote
1
down vote













Solution: Nested SSH session.



alice may log into bob's workstation (foo:22) via SSH with the identity of bob, and then log into baz via SSH with bob's identity (and his key, as they both are now accessible to alice).



A command-based representation of this:



alice@bar:~$ ssh bob@foo
bob@foo's password:
---snip----
bob@foo:~$ ssh -i /home/bob/.ssh/id_rsa (your-user)@baz
----RSA ID based authentication----
your-user@baz:~$


Diagrammatical representation:



alice@bar -> Log into foo as user bob -> use bob's stored key to log into baz -> Achieved!





share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417206%2fshare-ssh-session-key-with-remote-user%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    2
    down vote



    accepted










    Alice can give Bob her public key, and Bob can add a line to his own .ssh/authorized_keys file that will allow Alice to start a ssh session (as Bob) on Bob's workstation foo. Using the command= option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection to baz as Bob, and using a key locally accessible to Bob on bar.



    command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever



    Optionally, you can include further constraint options (no-port-forwarding, from=, etc. - see sshd man page section on AUTHORIZED_KEYS FILE FORMAT).



    When Alice runs ssh bob@bar and authenticates with her private key, she will be connected through bar to a ssh session on baz, without having any control over the intermediate session on Bob's workstation.



    Note that from the perspective of baz (logging, security audit), there is no distinction between this tunneled connection initiated by Alice, and a "normal" connection by Bob from his own workstation. This may be what you asked for, but not what you want.



    For making the protected key available to Alice for her session, you can explicitly set the environment variable SSH_AUTH_SOCK to be the path that Bob uses for his session (change the authorized_keys entry to command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...) To avoid having to update the path when it changes (logoff/login typically), Bob can run a dedicated agent on Alice's behalf with an explicit path specified (ssh-agent -a ~/.ssh/agent_for_alice and add only the specific key with SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa and entering the passphrase.






    share|improve this answer























    • Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
      – mschilli
      Jan 17 at 14:08






    • 1




      Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
      – PKapp
      Jan 18 at 2:30










    • Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
      – mschilli
      Jan 18 at 9:34

















    up vote
    2
    down vote



    accepted










    Alice can give Bob her public key, and Bob can add a line to his own .ssh/authorized_keys file that will allow Alice to start a ssh session (as Bob) on Bob's workstation foo. Using the command= option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection to baz as Bob, and using a key locally accessible to Bob on bar.



    command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever



    Optionally, you can include further constraint options (no-port-forwarding, from=, etc. - see sshd man page section on AUTHORIZED_KEYS FILE FORMAT).



    When Alice runs ssh bob@bar and authenticates with her private key, she will be connected through bar to a ssh session on baz, without having any control over the intermediate session on Bob's workstation.



    Note that from the perspective of baz (logging, security audit), there is no distinction between this tunneled connection initiated by Alice, and a "normal" connection by Bob from his own workstation. This may be what you asked for, but not what you want.



    For making the protected key available to Alice for her session, you can explicitly set the environment variable SSH_AUTH_SOCK to be the path that Bob uses for his session (change the authorized_keys entry to command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...) To avoid having to update the path when it changes (logoff/login typically), Bob can run a dedicated agent on Alice's behalf with an explicit path specified (ssh-agent -a ~/.ssh/agent_for_alice and add only the specific key with SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa and entering the passphrase.






    share|improve this answer























    • Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
      – mschilli
      Jan 17 at 14:08






    • 1




      Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
      – PKapp
      Jan 18 at 2:30










    • Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
      – mschilli
      Jan 18 at 9:34















    up vote
    2
    down vote



    accepted







    up vote
    2
    down vote



    accepted






    Alice can give Bob her public key, and Bob can add a line to his own .ssh/authorized_keys file that will allow Alice to start a ssh session (as Bob) on Bob's workstation foo. Using the command= option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection to baz as Bob, and using a key locally accessible to Bob on bar.



    command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever



    Optionally, you can include further constraint options (no-port-forwarding, from=, etc. - see sshd man page section on AUTHORIZED_KEYS FILE FORMAT).



    When Alice runs ssh bob@bar and authenticates with her private key, she will be connected through bar to a ssh session on baz, without having any control over the intermediate session on Bob's workstation.



    Note that from the perspective of baz (logging, security audit), there is no distinction between this tunneled connection initiated by Alice, and a "normal" connection by Bob from his own workstation. This may be what you asked for, but not what you want.



    For making the protected key available to Alice for her session, you can explicitly set the environment variable SSH_AUTH_SOCK to be the path that Bob uses for his session (change the authorized_keys entry to command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...) To avoid having to update the path when it changes (logoff/login typically), Bob can run a dedicated agent on Alice's behalf with an explicit path specified (ssh-agent -a ~/.ssh/agent_for_alice and add only the specific key with SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa and entering the passphrase.






    share|improve this answer














    Alice can give Bob her public key, and Bob can add a line to his own .ssh/authorized_keys file that will allow Alice to start a ssh session (as Bob) on Bob's workstation foo. Using the command= option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection to baz as Bob, and using a key locally accessible to Bob on bar.



    command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever



    Optionally, you can include further constraint options (no-port-forwarding, from=, etc. - see sshd man page section on AUTHORIZED_KEYS FILE FORMAT).



    When Alice runs ssh bob@bar and authenticates with her private key, she will be connected through bar to a ssh session on baz, without having any control over the intermediate session on Bob's workstation.



    Note that from the perspective of baz (logging, security audit), there is no distinction between this tunneled connection initiated by Alice, and a "normal" connection by Bob from his own workstation. This may be what you asked for, but not what you want.



    For making the protected key available to Alice for her session, you can explicitly set the environment variable SSH_AUTH_SOCK to be the path that Bob uses for his session (change the authorized_keys entry to command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...) To avoid having to update the path when it changes (logoff/login typically), Bob can run a dedicated agent on Alice's behalf with an explicit path specified (ssh-agent -a ~/.ssh/agent_for_alice and add only the specific key with SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa and entering the passphrase.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 18 at 11:21

























    answered Jan 17 at 13:02









    PKapp

    35112




    35112












    • Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
      – mschilli
      Jan 17 at 14:08






    • 1




      Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
      – PKapp
      Jan 18 at 2:30










    • Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
      – mschilli
      Jan 18 at 9:34




















    • Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
      – mschilli
      Jan 17 at 14:08






    • 1




      Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
      – PKapp
      Jan 18 at 2:30










    • Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
      – mschilli
      Jan 18 at 9:34


















    Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
    – mschilli
    Jan 17 at 14:08




    Thx for the reply. Regarding your last paragraph, that is what I asked for and also what I want. Regarding the rest: As I wrote in the addendum to my question, I already tried that following @mukesh-sai-kumar's answer. The problem is that bob's key requires a password that alice must not know. Using ssh-agent && ssh-add bob can load the key using his password and the ssh baz using that key without password but I could not figure out how to share that loaded key with bob's session on foo under alices control from bar.
    – mschilli
    Jan 17 at 14:08




    1




    1




    Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
    – PKapp
    Jan 18 at 2:30




    Bob can prefix the command in authorized_keys with an explicit environment variable setting for SSH_AUTH_SOCK to grant Alice access to his own running agent. Probably better to run a dedicated agent for Alice (using ssh-agent -a ~/.ssh/agent_for_alice, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then the authorized_keys entry can read command="SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh bob@baz -p 22" ssh-rsa AAA...
    – PKapp
    Jan 18 at 2:30












    Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
    – mschilli
    Jan 18 at 9:34






    Thx for the missing piece. Would you mind editing your answer to include that part to make it more clear for future readers?
    – mschilli
    Jan 18 at 9:34














    up vote
    1
    down vote













    Solution: Nested SSH session.



    alice may log into bob's workstation (foo:22) via SSH with the identity of bob, and then log into baz via SSH with bob's identity (and his key, as they both are now accessible to alice).



    A command-based representation of this:



    alice@bar:~$ ssh bob@foo
    bob@foo's password:
    ---snip----
    bob@foo:~$ ssh -i /home/bob/.ssh/id_rsa (your-user)@baz
    ----RSA ID based authentication----
    your-user@baz:~$


    Diagrammatical representation:



    alice@bar -> Log into foo as user bob -> use bob's stored key to log into baz -> Achieved!





    share|improve this answer

























      up vote
      1
      down vote













      Solution: Nested SSH session.



      alice may log into bob's workstation (foo:22) via SSH with the identity of bob, and then log into baz via SSH with bob's identity (and his key, as they both are now accessible to alice).



      A command-based representation of this:



      alice@bar:~$ ssh bob@foo
      bob@foo's password:
      ---snip----
      bob@foo:~$ ssh -i /home/bob/.ssh/id_rsa (your-user)@baz
      ----RSA ID based authentication----
      your-user@baz:~$


      Diagrammatical representation:



      alice@bar -> Log into foo as user bob -> use bob's stored key to log into baz -> Achieved!





      share|improve this answer























        up vote
        1
        down vote










        up vote
        1
        down vote









        Solution: Nested SSH session.



        alice may log into bob's workstation (foo:22) via SSH with the identity of bob, and then log into baz via SSH with bob's identity (and his key, as they both are now accessible to alice).



        A command-based representation of this:



        alice@bar:~$ ssh bob@foo
        bob@foo's password:
        ---snip----
        bob@foo:~$ ssh -i /home/bob/.ssh/id_rsa (your-user)@baz
        ----RSA ID based authentication----
        your-user@baz:~$


        Diagrammatical representation:



        alice@bar -> Log into foo as user bob -> use bob's stored key to log into baz -> Achieved!





        share|improve this answer












        Solution: Nested SSH session.



        alice may log into bob's workstation (foo:22) via SSH with the identity of bob, and then log into baz via SSH with bob's identity (and his key, as they both are now accessible to alice).



        A command-based representation of this:



        alice@bar:~$ ssh bob@foo
        bob@foo's password:
        ---snip----
        bob@foo:~$ ssh -i /home/bob/.ssh/id_rsa (your-user)@baz
        ----RSA ID based authentication----
        your-user@baz:~$


        Diagrammatical representation:



        alice@bar -> Log into foo as user bob -> use bob's stored key to log into baz -> Achieved!






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 15 at 13:58









        Mukesh Sai Kumar

        27819




        27819






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417206%2fshare-ssh-session-key-with-remote-user%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Morgemoulin

            Scott Moir

            Souastre