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 more thinks that I should have clarified:
bob
doesn't wantalice
to know his passwordbob
doesn't wantalice
to be able to runrm -rf /home/bob
onfoo
(onbaz
however that would be fine obviously).
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 initiated by the ssh
from alice
(via ssh-agent
?) .
Best 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 workstationfoo
. Using thecommand=
option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection tobaz
as Bob, and using a key locally accessible to Bob onbar
.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. - seesshd
man page section on AUTHORIZED_KEYS FILE FORMAT).When Alice runs
ssh bob@bar
and authenticates with her private key, she will be connected throughbar
to a ssh session onbaz
, 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 theauthorized_keys
entry tocommand="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 withSSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa
and entering the passphrase.