Ich antworte selbst, als ich endlich das Geheimnis entdeckt habe. Weder die -tOption für sshnoch die -lOption für bashführt dazu, dass sich die Shell selbst anmeldet - aber in Kombination funktionieren sie.
ssh user@host.com -t 'cd /some/where; FOO=BAR NUMBER=42 bash -l'wechselt das Verzeichnis, setzt Umgebungsvariablen und startet dann die richtige Login-Shell (der einzige Unterschied, den ich bisher festgestellt habe, ist, dass dies /etc/motdnicht so angezeigt wird - normalerweise liegt es in der Verantwortung sshoder loginder Verantwortung, nicht in der Verantwortung bash- ansonsten scheint alles perfekt funktionieren, und alle Umgebungsvariablen sind identisch).
Diese Änderungen an der Umgebung / im Verzeichnis erfolgen nach ssh. Sie werden also nicht durch die PermitUserEnvironmententsprechenden Einstellungen (genau wie geplant) beschränkt, sondern vor .bashrc/ .profileget ausgeführt. Dies hat Vor- und Nachteile - es ist schwieriger, nur etwas zu überschreiben, das von Bash-Init-Skripten wie gesetzt wird PS1, aber es ist einfacher, genau die richtigen Werte in sshBefehlszeilen zu packen und .profileall das schwere Heben zu erledigen.
Und wenn es wirklich nötig ist, ist es eigentlich ziemlich einfach, bash dazu zu bringen, etwas auszuführen, das danach .profilemit einer Befehlszeile wie folgt aussieht ssh user@foo.com -t 'cd /mnt; echo ". ~/.bash_profile; PS1=\"\\h-\w \"" >~/xxx; bash --init-file ~/xxx'- sehr hässlich, wenn man das so formuliert, aber diese alternativen .profileDateien können vorher vorbereitet werden. (Soweit ich das beurteilen kann, bashgibt es ein paar Kandidaten für ein .profileSkript und es wird das erste ausgeführt, das gefunden wurde. Es . filegibt keine solchen automatischen Fallbacks. Sie müssen also überprüfen, wo Sie normal sind, profilewenn Sie das tun möchten.)