Considere o seguinte cenário:
Estou logado no serverA como um usuário 'comum'. O principal sobrecomum usuário é que muitas pessoas têm acesso a ele - ele é irrestrito e inseguro por design.
Digamos que eu periodicamente precise fazer login deste usuário/servidor paraservidorBcomo usuárioseguro- ou seja, preciso de arquivos scp de propriedade deseguro@servidorB.
Embora eu tenha acesso e controle total sobresegurousuário, certamente não quero adicionarcomumda chave pública para chaves confiáveis parasegurousuário - não quero ninguém que possa fazer login comocomumpara poder fazer login comosegurotambém.
Eu também não quero digitarsegurosenha 5 vezes por hora. Idealmente, eu gostaria de digitá-lo uma vez, fazer com que algum agente lembre-se dele magicamente - mas apenas para esta sessão de login - e usá-lo sempre que me conectar a partir desta sessão até que o tempo limite expire. Não muito diferente kinit, na verdade.
Existe alguma coisa lá fora que possa atingir esse objetivo?
Responder1
Não é tão fácil se você compartilhou o usuário no servidor intermediário e esse usuário tem acesso ao shell, pois quase tudo que existe por padrão é acessível por cada outra sessão.
Existem maneiras nos kernels modernos, é claro.
Ou poderia haver uma ferramenta que utiliza chaveiros de sessão (processo/thread) para armazenar os dados privados no kernel ou o sistema provavelmente pode ser tornado seguro o suficiente para impedir que diferentes processos do mesmo usuário acessem uns aos outros para que um programa possa manter o informações de autenticação também na memória normal do espaço do usuário protegida de outras sessões. De qualquer forma, ambos tiveram que identificar solicitações para fazer a autenticação com base em algumas informações de PID/SID que funcionarão para uso básico. No final, você precisa de um daemon que configure a sessão para você ou entregue as senhas armazenadas ao seu processo para que você possa usá-lo com a ferramenta sshpass ou algo semelhante.
Outra abordagem é utilizar namespaces e montar um tmpfs ou tmpdir privado (enquanto o tmpfs é melhor protegido ou pelo menos menos acessível para usuários root do que o tmpdir).
Você pode usar sshd em uma porta separada com um wrapper que configura o ambiente de namespace para esse usuário, ou mais facilmente em um sistema moderno, pelo menos. Você pode usar pam e pam_namespace.so para configurar um usuário privado tmpdir ou tmpfs. Lá você pode armazenar sua senha em texto não criptografado para ser usada pelo sshpass ou algo assim, ou melhor ainda, pode colocar o soquete para ssh-agent nesse diretório e carregar sua chave privada pessoal nesse agente, garantindo que o acesso ao agente esteja protegido contra acesso por outras sessões do mesmo usuário. Se você tiver uma chave privada com senha forte, também poderá armazená-la na máquina. Caso contrário, você teria que transferi-lo. Você também pode tornar todo o diretório /tmp um diretório privado (possivelmente com alguns subdiretórios compartilhados) e utilizar o encaminhamento do agente SSH de uma maneira bastante segura (você não pode realmente protegê-lo para ser abusado pelo usuário root, mas pelo menos se você usar tmpfs é difícil para o root e não é possível para o usuário normal usar o Auth-Sock).
De qualquer forma, você precisa ser capaz de configurar o servidor suficientemente ou ele precisa ser configurado o suficiente - pelo menos até o ponto em que os processos dos usuários não possam se conectar uns aos outros.
Responder2
Você provavelmente está procurandossh-agent, que vem com OpenSSH. Use a -topção para definir um tempo limite.