Alice pode dar a Bob sua chave pública, e Bob pode adicionar uma linha ao seu próprio arquivo .ssh/authorized_keys
que permitirá que Alice inicie uma sessão ssh (como Bob) na estação de trabalho de Bob foo
. Usando a opção command=
, Bob pode restringir a chave de Alice para não conceder um shell interativo, mas uma conexão ssh aninhada a baz
como Bob e usando uma chave acessada localmente para Bob em bar
.
command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever
Opcionalmente, você pode incluir outras opções de restrição ( no-port-forwarding
, from=
, etc. - consulte a seção da página sshd
man em AUTHORIZED_KEYS FILE FORMAT).
Quando Alice executar ssh bob@bar
e autenticar com sua chave privada, ela será conectada por meio de bar
a uma sessão ssh em baz
, sem ter nenhum controle sobre a sessão intermediária na estação de trabalho de Bob.
Observe que, do ponto de vista de baz
(log, auditoria de segurança), não há distinção entre essa conexão em túnel iniciada por Alice e uma conexão "normal" por Bob de sua própria estação de trabalho. Isso pode ser o que você pediu, mas não o que você quer.
Para tornar a chave protegida disponível para Alice em sua sessão, você pode definir explicitamente a variável de ambiente SSH_AUTH_SOCK
como o caminho que Bob usa para sua sessão (altere a entrada authorized_keys
para command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...
). para atualizar o caminho quando ele é alterado (logoff / login normalmente), Bob pode executar um agente dedicado em nome de Alice com um caminho explícito especificado ( ssh-agent -a ~/.ssh/agent_for_alice
e adicionar somente a chave específica com SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa
e inserindo a frase secreta.