share ssh session/key with remote user
up vote
5
down vote
favorite
Assume the following setup:
- User
bob
is working locally on his workstationfoo
. - User
alice
is working locally on her workstationbar
. - User
bob
has ssh access to serverbaz:22
via a key stored atbob@foo:.ssh/id_rsa
. - User
alice
has ssh access tobob
's workstationfoo:22
but not to serverbaz
.
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:
bob
doesn't wantalice
to know his password
bob
doesn't want alice to be able to runrm -rf /home/bob
onfoo
(onbaz
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
add a comment |
up vote
5
down vote
favorite
Assume the following setup:
- User
bob
is working locally on his workstationfoo
. - User
alice
is working locally on her workstationbar
. - User
bob
has ssh access to serverbaz:22
via a key stored atbob@foo:.ssh/id_rsa
. - User
alice
has ssh access tobob
's workstationfoo:22
but not to serverbaz
.
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:
bob
doesn't wantalice
to know his password
bob
doesn't want alice to be able to runrm -rf /home/bob
onfoo
(onbaz
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
@JeffSchaller: Thx for the typo fix. :-)
– mschilli
Dec 5 at 14:16
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
Assume the following setup:
- User
bob
is working locally on his workstationfoo
. - User
alice
is working locally on her workstationbar
. - User
bob
has ssh access to serverbaz:22
via a key stored atbob@foo:.ssh/id_rsa
. - User
alice
has ssh access tobob
's workstationfoo:22
but not to serverbaz
.
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:
bob
doesn't wantalice
to know his password
bob
doesn't want alice to be able to runrm -rf /home/bob
onfoo
(onbaz
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
Assume the following setup:
- User
bob
is working locally on his workstationfoo
. - User
alice
is working locally on her workstationbar
. - User
bob
has ssh access to serverbaz:22
via a key stored atbob@foo:.ssh/id_rsa
. - User
alice
has ssh access tobob
's workstationfoo:22
but not to serverbaz
.
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:
bob
doesn't wantalice
to know his password
bob
doesn't want alice to be able to runrm -rf /home/bob
onfoo
(onbaz
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
ssh ssh-tunneling ssh-agent
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
add a comment |
@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
add a comment |
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.
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 thatbob
's key requires a password thatalice
must not know. Usingssh-agent
&&ssh-add
bob
can load the key using his password and thessh baz
using that key without password but I could not figure out how to share that loaded key withbob
's session onfoo
underalices
control frombar
.
– mschilli
Jan 17 at 14:08
1
Bob can prefix the command inauthorized_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 (usingssh-agent -a ~/.ssh/agent_for_alice
, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then theauthorized_keys
entry can readcommand="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
add a comment |
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!
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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.
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 thatbob
's key requires a password thatalice
must not know. Usingssh-agent
&&ssh-add
bob
can load the key using his password and thessh baz
using that key without password but I could not figure out how to share that loaded key withbob
's session onfoo
underalices
control frombar
.
– mschilli
Jan 17 at 14:08
1
Bob can prefix the command inauthorized_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 (usingssh-agent -a ~/.ssh/agent_for_alice
, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then theauthorized_keys
entry can readcommand="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
add a comment |
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.
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 thatbob
's key requires a password thatalice
must not know. Usingssh-agent
&&ssh-add
bob
can load the key using his password and thessh baz
using that key without password but I could not figure out how to share that loaded key withbob
's session onfoo
underalices
control frombar
.
– mschilli
Jan 17 at 14:08
1
Bob can prefix the command inauthorized_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 (usingssh-agent -a ~/.ssh/agent_for_alice
, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then theauthorized_keys
entry can readcommand="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
add a comment |
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.
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.
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 thatbob
's key requires a password thatalice
must not know. Usingssh-agent
&&ssh-add
bob
can load the key using his password and thessh baz
using that key without password but I could not figure out how to share that loaded key withbob
's session onfoo
underalices
control frombar
.
– mschilli
Jan 17 at 14:08
1
Bob can prefix the command inauthorized_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 (usingssh-agent -a ~/.ssh/agent_for_alice
, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then theauthorized_keys
entry can readcommand="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
add a comment |
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 thatbob
's key requires a password thatalice
must not know. Usingssh-agent
&&ssh-add
bob
can load the key using his password and thessh baz
using that key without password but I could not figure out how to share that loaded key withbob
's session onfoo
underalices
control frombar
.
– mschilli
Jan 17 at 14:08
1
Bob can prefix the command inauthorized_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 (usingssh-agent -a ~/.ssh/agent_for_alice
, and adding only the single key she needs to that agent, by explicitly setting SSH_AUTH_SOCK). Then theauthorized_keys
entry can readcommand="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
add a comment |
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!
add a comment |
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!
add a comment |
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!
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!
answered Jan 15 at 13:58
Mukesh Sai Kumar
27819
27819
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
@JeffSchaller: Thx for the typo fix. :-)
– mschilli
Dec 5 at 14:16