Colocando o socket de controle OpenSSH em / run

4

O OpenSSH possui um recurso que permite multiplexar conexões por meio de um controle de controles. É geralmente aceito que esses soquetes de controle não devem residir em uma área comum, devido aos problemas de segurança gerados por soquetes acessíveis publicamente.

Também é uma política geral usar algo como ~/.ssh/sockets como o local dos soquetes. Isso representa um problema com o qual venho lidando há algum tempo.

Quando o processo mestre é finalizado com força e a limpeza não é feita, o armazenamento de soquete ficará cheio de soquetes que você precisa limpar manualmente. Exemplos de tal caso seriam uma perda de energia ou outra falha de hardware.

As distribuições Linux modernas transportam /run , que contém dados de tempo de execução voláteis, juntamente com /run/user/<uid> , que é destinado a dados de tempo de execução voláteis por usuário. O diretório é acessível apenas pelo proprietário e é criado pelo sistema para o usuário.

Considerando que os soquetes de controle se encaixam perfeitamente nesta descrição, eu adoraria transferir o soquete para lá. No entanto, há certos problemas. A configuração do OpenSSH permite apenas que você direcione o usuário atual pelo nome do usuário, onde o diretório é criado para o UID do usuário. Eu compartilho minha configuração geral entre hosts, então codificar o UID na configuração não é algo que eu queira fazer.

O que estou procurando é uma solução limpa que permita usar uma configuração OpenSSH genérica de forma que os soquetes sejam limpos na inicialização.

    
por Ressu 09.01.2015 / 08:21

1 resposta

1

Desde o OpenSSH 7.2, que foi lançado em fevereiro de 2016, o %i agora é suportado na expressão ControlPath , que se expande para o UID numérico.

Por exemplo,

ControlPath /run/user/%i/master-%l-%r@%h:%p

Como alternativa, se o OpenSSH mais novo não estiver disponível, você pode considerar o uso de /dev/shm para armazenar dados temporários. É mundialmente gravável e é sempre tmpfs . Embora seja acessível a outros usuários, os próprios soquetes de controle têm direitos de acesso adequados, portanto, deve ser seguro.

link

    
por 14.07.2016 / 14:08