Supondo que o usuário tenha /bin/bashcomo shell /etc/passwd. Em seguida, ssh user@host commandexecuta o comando usando o Bash. No entanto, esse shell não é nem logado nem interativo, o que significa que ~/.bash_profilenem ~/.bashrcé originário. Nesse caso, como definir a PATHvariável de ambiente para que os executáveis possam ser encontrados e executados? É recomendável prefixar o comando real com source ~/.bashrc?
Respostas:
Você tem poucas possibilidades:
PATHservidor em ~/.ssh/environment(precisa ser ativado por PermitUserEnvironment yesin sshd_config)..bashrc: prefixe o comando com . ~/.bashrc(ou source)Depende do caso de uso, para que lado você irá.
~/.bashrcnão é necessário, acontece por padrão. De fato, parece-me uma má ideia.
$PATHnão expande de ~/.ssh/environment, pelo menos não entra OpenSSH_7.9p1, OpenSSL 1.1.1b 26 Feb 2019.
PermitUserEnvironment(padrão nas versões recentes)
PATH="$PATH:/new/path"ao meu ~/.ssh/environment, quando deveria ter sidoPATH=$PATH:/new/path
Você está equiparando as configurações locais a remotas .
Localmente, uma instância do bash, o atual shell em execução no qual você escreve:
ssh user@host commandIrá executar o comando ssh (nada mais) como um cliente ssh.
Para fazer isso, o shell local não precisa iniciar um sub shell ou um novo shell ou login.
O comando é executado como um ls comando é: localmente.
É o comando client ssh que abre uma conexão de rede com um sistema remoto , onde, se autenticado corretamente, um novo shell será iniciado para executar o comando escrito como argumento para o ssh ou, se nenhum argumento for fornecido, espere mais comandos nessa conexão.
Esse novo controle remoto shell necessariamente será um shell de login, pois o usuário remoto (nesse sistema) precisa ser autenticado para efetuar o login. Ou, se algum comando específico for fornecido, basta executar esse comando com os privilégios de usuário autenticado.
Você pode ver quais arquivos são originados adicionando um $file sourcedao início de cada arquivo (no sistema remoto ) (é necessária a raiz para alterar os /etc/arquivos):
$ a=(~/.bashrc ~/.profile /etc/bash.bashrc /etc/profile)
$ for f in "${a[@]}"; do sed -i '1 i\echo "'"$f"' was read"\n' "$f"; doneE então basta iniciar um console ssh:
$ ssh sorontar@localhost
/etc/profile was read
/etc/bash.bashrc was read
/home/sorontar/.profile was read
/home/sorontar/.bashrc was readNesse caso, os dois bashrcarquivos foram lidos porque cada profilearquivo tinha comandos para incluí-los, não porque o shell de login os originou diretamente.
$ ssh sorontar@localhost :
/etc/bash.bashrc was read
/home/sorontar/.bashrc was readNeste sistema, onde bashrcé lido nos dois casos.
Não é necessário adicionar um source ~/.bashrcao comando para executar.
Tudo o que você precisa fazer é incluir as configurações corretas para alterar o "$ PATH", /etc/bash.bashrcpara todos os usuários que iniciam um shell neste sistema. Ou ~/.bashrcpara cada usuário que precisar. Você pode adicionar (ou editar) um esqueleto de um usuário .bashrcao/etc/skel/ ter qualquer novo usuário criado tem o arquivo correto disponível.
O acima é válido apenas para o bash. Se você precisar que a configuração funcione para todos os shells, provavelmente defina a variável de ambiente PATH usando o arquivo ssh ~/.ssh/environmentpara cada usuário que precisar. Ou use /etc/ssh/sshrcpara uma configuração global no sistema em que o servidor ssh está em execução (leia a seção Arquivos man sshdpara obter mais detalhes).
.bashrcé originário, mas provavelmente tem um teste de interatividade na parte superior. As coisas que você colocou antes dessa verificação devem ser aplicadas, e é isso que faço para forçar o PATH quando o servidor não permite o ambiente ou o uso do usuário~/.pam_environment.