transfere informações sobre a conexão do cliente ssh para o servidor ssh

Question

suponha que eu tenha a seguinte sessão ssh:

userA@boxA -> userB@boxB -> userC@boxC

agora, de boxC , como userC , gostaria de ter as informações de que a conexão ssh veio de userB@boxB , que, por sua vez, veio de userA@boxA .

agora eu tenho a seguinte sessão ssh junto com a primeira sessão ssh:

userD@boxD -> userB@boxB

de boxB , como userB , gostaria de ter a informação de que a conexão veio de userD@boxD e que há uma segunda sessão ssh proveniente de userA@boxA .

esta informação está disponível e acessível como usuário? está mesmo disponível?

Se não, existe alguma maneira "fácil" de disponibilizar esta informação? com fácil, quero dizer, sem invadir e recompilar o sshd e sem ter que ter acesso root nas máquinas.

    

Answer 1

A maneira oficial de enviar variáveis de ambiente de cliente para servidor é através de SendEnv e AcceptEnv . O problema é que você precisa de acesso root no servidor para configurar AcceptEnv . A maioria dos servidores está configurada para aceitar não ou apenas algumas variáveis predeterminadas.

Eu encontrei dois truques para enviar variáveis de ambiente de cliente para servidor, ambos funcionam sem precisar de acesso root no servidor.

enganar um:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME bash

isso conectará ao servidor e executará o comando SSH_ORIGIN=$USERNAME@$HOSTNAME bash , com $USERNAME e $HOSTNAME já substituídos no lado do cliente. em seguida, no lado do servidor, você pode processar ainda mais as informações contidas na variável SSH_ORIGIN .

o -t é necessário caso contrário, o bash será iniciado no servidor sem um tty (experimente, você verá).

uma ligeira modificação permitirá passar a informação de forma transitiva por uma cadeia ssh mais longa.

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN bash

discussão:

• o bash é iniciado como um shell interativo de não-login ( .profile não é lido).
• o bash é executado duas vezes ( .bashrc é lido duas vezes). uma vez por sshd e uma vez pelo comando do usuário.
• ele sempre iniciará o bash, ignorando seu shell padrão no servidor.

truque dois:

Primeiro você deve gerar uma chave ssh e transferi-la para ~/.ssh/authorized_keys no servidor. em seguida, prefixar a linha com command="$SHELL" . veja a página de manual do sshd para mais informações sobre isso.

conecte-se ao servidor ssh usando o comando:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME

isto irá se conectar ao servidor, mas desta vez a atribuição da variável não será executada. em vez disso, a string é armazenada na variável de ambiente $SSH_ORIGINAL_COMMAND . então o comando fornecido em ~/.ssh/authorized_keys é executado. Quando você estiver no shell, poderá processar as informações contidas em $SSH_ORIGINAL_COMMAND .

como acima, você pode tornar isso transitivo:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN

discussão:

• ele iniciará o shell padrão no servidor.
• sempre iniciará o shell padrão no servidor. qualquer comando que você der ao comando ssh será ignorado e armazenado em $SSH_ORIGINAL_COMMAND . Se você quer executar um comando sobre o ssh, você pode usar uma chave ssh diferente ou ter seu arquivo init do shell para detectar e executar $SSH_ORIGINAL_COMMAND .

Answer 2

O comando who informa quem mais está logado agora na mesma máquina e de onde eles efetuaram login. O comando last fornece as mesmas informações para as sessões anteriores. Dependendo da configuração da máquina e dos métodos de login, as informações podem nem sempre estar completas, atualizadas ou disponíveis para usuários não-root.

Em seu cenário A @ A- > B @ B- > C @ C, é impossível da máquina C saber que B @ B foi logado em B através de uma sessão ssh de A. Na década de 80, quando todo mundo confiava em todos, você poderia ter tentado finger ou ident , mas atualmente a máquina B provavelmente nem está executando um dedo ou ident daemon.

    

Answer 3

Eu acho que você poderia forçar a variável de ambiente no hostB a gravar o endereço do hostA. Em seguida, no hostC, use AcceptEnv para obter o ambiente do hostB, voila:)

leia sshd_config um pouco, partes sobre coisas do ambiente.

    

Answer 4

Do Box C, sem acesso ao Box B, você não seria capaz de dizer que o usuário tinha vindo do Box A. De fato, você pode não ser capaz de dizer como o usuário chegou ao Box C. Ele simplesmente depende sobre como o administrador configurou as coisas.

Mesma resposta para a pergunta "suponha mais". Depende das permissões que o administrador do sistema deu a você e dos programas que ele instalou.

Comandos relevantes que ajudariam se você tivesse permissões (mas provavelmente não o fazem):

finger - http://www.manpagez.com/man/1/finger/

last - http://www.manpagez.com/man/1/last/