Por que "ssh -t" não está funcionando tanto quanto fazer login e executar um comando?

A principal diferença neste caso é que ssh hostinicia o seu shell de login no modo de login ( sshdinicia-o com -prefixo ao seu argv[0]que diz ao shell que ele deve inicializar a sessão de login lendo um script de inicialização .profile, .bash_profile, .zprofile, .zloginou .login(e possivelmente os do sistema em /etc) dependendo na implementação do shell) e interativamente (na medida em que emite prompts para obter entrada de você). Esse é o rloginmodo de ssh.

Enquanto estiver em ssh -t host 'some shell code', sshdexecuta seu shell de login com -ce some shell codecomo argumento, mas sem dizer que é um shell de login. Esse shell também não é interativo, o código não é solicitado a partir de um terminal. Esse é o rshmodo.

E provavelmente no seu caso, o comando não pode ser encontrado porque algumas diretivas nos arquivos de inicialização de sessão para definir a $PATHvariável não foram executadas.

Observe que nem todos os shells podem ser um shell de login e interpretar o código fornecido como argumento.

A bashcasca pode embora. bashiniciará como um shell de login quando for argv[0]iniciado com , -mas também quando passar uma opção -lou --login, e então1¹ ainda lerá os arquivos de inicialização da sessão de login mesmo se passar um comando para executar -c(exceto no modo POSIX).

Então aqui, em vez de fazer:

ssh -t host 'some code'

Você poderia fazer:

ssh -t host "exec bash --login -c 'some code'"

Que iniciará outro bash, mas desta vez como um shell de login (que interpretará o código ~/.bash_profilee possivelmente algum em /etc/profileou /etc/profile.donde $PATHestá a inicialização) antes de interpretar o some code.

Ou você pode tentar localizar o arquivo onde a $PATHdefinição é feita e fazer:

ssh -t host '. /path/to/that/file && some code'

Isso ainda deixa outra diferença, pois esse shell não é interativo e seus arquivos de inicialização podem decidir se comportar de maneira diferente quando interativos de quando não são (verificando a presença de iin $-ou verificando a presença de uma $PS1variável).

bashnão interpreta ~/.bashrc(o arquivo de personalização do shell interativo) na inicialização quando executado como um shell de login, mesmo quando interativo (ao contrário do que acontece na maioria dos outros shells), mas a maioria das pessoas contorna essa decisão de design bizarra adicionando um source ~/.bashrcem seus arquivos ~/.bash_profile. O padrão ~/.profileno Debian e derivados faz isso por padrão (somente quando o shell é bashclaro).

bashnão interpreta ~/.bashrcquando invocado por ssh por padrão, mas pode ser configurado em tempo de compilação para fazê-lo usando a SSH_SOURCE_BASHRCopção de configuração. Debian e derivados como o Ubuntu permitem isso. Portanto, ao fazer ssh ubuntu-host 'some code', e se seu shell de login for bash nessa máquina, o bashshell que sshdiniciará interpretará ~/.bashrcantes de interpretar some code.

O ~/.bashrcmesmo acaba sendo interpretado no modo rlogine rsh, mas, conforme observado por @Quasimodo, o padrão ~/.bashrcno Debian e no Ubuntu tem isso no topo:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Portanto, se houver uma $PATHdefinição abaixo dessas linhas, elas serão interpretadas apenas no rloginmodo (onde bashé interativo, $-contém ie ~/.bashrcé originado por ~/.profile), e não no rshmodo (onde ~/.bashrcé originado, mas a maior parte de seu conteúdo é ignorada como o shell não é interativo).

^{¹ no caso de argv[0]iniciar com -(ao invés de com -l/ --login), se ele será tratado como shell de login ou não quando passado a -c codedepende se bashfoi compilado com NON_INTERACTIVE_LOGIN_SHELLShabilitado ou não.}

Você está perdendo as configurações de ambiente, pois esses dois cenários nem sempre são equivalentes:

ssh remoteHost
someCommand

ssh -t remoteHost someCommand

Este próximo bloco de comando lhe dará o conjunto de variáveis ​​que estão faltando em sua solução preferida (o segundo formato nos dois exemplos acima). Você pode adicioná-los à sua pergunta e eu vou completar esta para explicar como defini-los, ou você mesmo pode usar as informações para defini-los.

ssh -t myvirtual.local env | grep = | sort >/tmp/env.1
( echo env; echo exit ) | ssh -tt myvirtual.local | grep = | sort >/tmp/env.2
comm -13 /tmp/env.1 /tmp/env.2

Saída de exemplo abreviada de um sistema que tenho aqui

EDITOR=vi
HISTCONTROL=ignoredups
LESSCLOSE=/usr/bin/lesspipe %s %s
LESSOPEN=| /usr/bin/lesspipe %s
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:...
PAGER=less
PATH=/home/roaima/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin:/bin
PROMPT_COMMAND_WAS=echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"
SHLVL=1
SSH_CLIENT=192.1.1.9 31996 22
SSH_CONNECTION=192.1.1.9 31996 192.1.1.18 22
TTY=/dev/pts/0
XDG_SESSION_ID=c61

Isso não tem nada específico para Ruby ou Rails, mas mostra que no meu caso a PATHvariável é diferente (você poderia ver os valores reais em /tmp/env.1and /tmp/env.2).

Depois de rastreá-lo e classificá-lo, você pode querer executar foremanem screenou tmux, para que ele não receba um SIGHUPsinal quando a sshconexão for encerrada. Mas eu recomendo que você comece resolvendo o problema inicial antes de introduzir qualquer uma dessas ferramentas adicionais.