Obtendo um .bashrc personalizado disponível na sessão ssh

Question

Atualmente, temos muitos logins ssh shared para vários servidores, e meus colegas não gostariam que eu mexesse muito no shell padrão. No entanto, tenho uma lista completa de aliases e funções personalizadas no meu .bashrc que eu gostaria de me seguir.

Além disso, como algumas conexões podem ser complicadas, a primeira coisa que eu gosto de fazer é iniciar uma sessão de tela, então se a conexão desistir de mim novamente, eu posso simplesmente voltar e continuar indo para onde eu saí. / p>

Atualmente, faço isso acrescentando uma string bastante complicada aos meus logins ssh:

ssh -t -l sharedname someserver.example.com 'if [ -z \'find ~ -maxdepth 1 -iname '.wrikken_bashrc.sh' -mtime -14 \' ]; then scp [email protected]:.bash_remote.sh ~/.wrikken_bashrc.sh; fi; screen -h 2000 -DR wrikken bash --rcfile ~/.wrikken_bashrc.sh'

Isso funciona satisfatoriamente (é claro que eu nunca precise digitá-lo uma vez definido no arquivo .bash_remote.sh ), mas duvido seriamente se essa é a solução correta. Além disso, ocasionalmente, ter que digitar minha senha para obter uma atualização do arquivo .wrikken_bashrc.sh é, obviamente, uma dor. Infelizmente, uma conta pessoal não é uma opção.

Resumindo: existe uma maneira melhor de ter meus aliases personalizados & funções me seguindo em torno de logins ssh?

    

Answer 1

Nossa equipe usa uma configuração semelhante em nossos servidores de desenvolvimento. Se nossos desenvolvedores precisarem executar comandos para controlar a instância do servidor, eles poderão usar nosso comando 'assume' - que é simplesmente um wrapper em torno do ssh. Os servidores de produção estão fora dos limites para os desenvolvedores, a menos que precisemos depurar algo sério.

Todo desenvolvedor autorizado a efetuar login na conta da instância do servidor possui uma entrada nas authorized_keys desse servidor ( Veja o arquivo AUTHORIZED_KEYS FORMATO DE ARQUIVO para detalhes ), mas cada chave autorizada tem um sinalizador que define uma variável de ambiente exclusiva para seu nome de usuário:

environment="SSHUSER=jason" ssh-rsa (BASE64-ENCODED-KEY) jason@localhost

Nesse exemplo da .bashrc, eu tenho um pequeno código:

USERHOME=$(eval "echo ~$SSHUSER")
if [ -f "$USERHOME/.client_bashrc" ]; then
    . "$USERHOME/.client_bashrc"
fi

Nossos desenvolvedores podem manter um arquivo .client_bashrc (separado de seu .bashrc) com permissões legíveis em seu diretório pessoal. Separar seus .bashrc de .client_bashrc ajuda na segurança, pois eles podem manter definições privadas e variáveis de ambiente em .bashrc. Opcionalmente, eles podem colocar uma linha de código em seu bashrc pessoal para simplesmente incluir .client_bashrc e manter ali aliases e definições que facilitam o trabalho com o sistema. (Isso tudo assume que o diretório home do usuário é acessível a partir do servidor dev.)

Warner faz uma boa observação em seu comentário de que essa configuração de nome de usuário compartilhado é contra as práticas recomendadas de segurança. Nosso sistema evoluiu de uma conta em um host compartilhado anos atrás. Estamos apenas chegando agora para limitar o poder das contas de desenvolvedores e mudar para um sistema em que as ações do desenvolvedor são colocadas em um log de auditoria.

    

Answer 2

É útil revisar o processo de login definido em man sshd para ver os locais onde é possível inserir um ambiente específico do usuário no login. O processo é:

1. imprime login e motd se for um tty ou a menos que ~ / .hushlogin
2. se fizer login em um tty; registra o login (observe que o LogLevel VERBOSE em sshd_config mostrará a chave de conexão usada para efetuar login
3. se o / etc / nologin existir, saia
4. mude para executar como usuário normal
5. configura o ambiente básico
6. lê ~/.ssh/environment se PermitUserEnvironment estiver definido em sshd_config
7. cds para o diretório pessoal do usuário
8. se ~ / .ssh / rc existir, executa-o; else se o / etc / ssh / sshrc existir, executa ... (principalmente para o X11)
9. executa o shell ou o comando do usuário.

Parece que usar ~ / .ssh / environment é a melhor maneira de controlar o ambiente por conexão. No entanto, como sugerido por Jason, isso pode ser feito definindo uma opção de ambiente em authorized_keys (se PermitUserEnvironment estiver habilitado). A variável de ambiente USER pode ser definida neste momento para um usuário diferente do usuário de login.

Substituir USER (e, a partir daí, o resto do ambiente) pode ser a melhor abordagem, tanto do ponto de vista do log no host quanto da conveniência dos usuários se conectarem a ele.

Infelizmente, os certificados ssh (não estou falando de chaves de identidade) não permitem especificar variáveis ambientais especificamente em um certificado de conexão. Se isso foi fornecido, a autoridade de certificação pode gerar certificados de cliente com o