ssh <host>是登录shell，但是ssh <host> <command>不是吗？

我注意到，当我使用ssh <host> <command>语法直接在SSH主机上运行命令时，看到的.bashrc是.bash_profile（或.profile）的输出，但看不到。

例如，如果我将以下命令放在两个文件的顶部，

echo ${BASH_SOURCE[0]}

和手动来源.bash_profile（.bashrc依次来源），我将看到

$ . .bash_profile
.bash_profile
.bashrc

如果使用ssh <host>命令的形式通过SSH远程登录到此计算机，则这与我看到的输出相同。（如果我.bash_profile暂时存放在其他地方，则这两行都不会被回显。）

但是，如果我直接在远程计算机上以的ssh <host> <command>形式执行命令ssh，则输出如下所示：

$ ssh <host> echo foo
/home/rlue/.bashrc
foo

我的理解是.bash_profile和之间的区别.bashrc是，前者用于登录shell，而后者用于交互式非登录shell。

我得出以下结论：

1. ssh <host>仅来源.bash_profile，而
2. ssh <host> <command>仅来源.bashrc，这意味着
3. 前者是登录外壳，而后者不是。

这些结论正确吗？为什么将其ssh <host> <command>视为交互式非登录外壳？SSH是否仍然登录到远程计算机以执行命令？

OpenSSH（很可能是您正在运行的内容）决定是否创建登录外壳，并且只有在未运行特定命令时才这样做。来自man ssh：

 If command is specified, it is executed on the remote host instead of a
 login shell.

因此，无论是否要创建登录shell，这都是ssh服务器的一种实现选择，并且如果您提供要运行的命令，则不是。

虽然ssh确实执行登录，但是如果要让它执行命令并退出，则与获取登录环境相比，它实际上更类似于创建仅用于运行该命令的shell。有鉴于此，编写OpenSSH的人们似乎决定将其视为此类任务。

他们创建了一个非交互式，非登录外壳程序来执行命令，因为这是在另一个上下文/外壳程序中运行命令的精神。但是，通常情况下，非交互式shell不会自动获得源代码~/.bashrc，这显然在这里发生。 bash实际上是在帮助我们。来自文档

由远程Shell守护程序调用

Bash尝试确定它何时在其标准输入连接到网络连接的情况下运行，就像由远程Shell守护程序（通常为rshd或安全Shell守护程序sshd）执行时一样。如果Bash确定它是以这种方式运行的，则它从〜/ .bashrc读取并执行命令（如果该文件存在并且可读）。如果作为sh调用，它将不会执行此操作。--norc选项可用于禁止此行为，而--rcfile选项可用于强制读取另一个文件，但是rshd和sshd通常都不会使用这些选项来调用shell或允许指定它们。

此行为的原因所在的层次比shell低：（ssh host“ login shell”情况）使用远程主机上的伪终端在sshd服务器进程和Shell 之间进行通信；ssh host command在sshd和之间使用管道command，而不是。伪终端对于交互使用命令解释器（例如shell）或脚本语言的“ read-eval-print ”模式是必不可少的。他们实现了许多对人类友好的功能，例如能够按错字退格。但是它们具有更多的开销，并且（取决于配置）不允许任意数据未经修改地传递，因此SSH避免在不进行交互时避免使用它们。

有时SSH的命令/无命令启发式方法会导致此错误；可以使用-t和-T开关覆盖它。例如，要登录到远程计算机并立即重新挂起挂起的screen会话，您需要执行ssh -t host screen -R；ssh host screen -R将导致screen抱怨没有连接到终端。我想不出您真正想使用的情况-T，但是只要您找到它，它就会在那里。

首先，您需要查看不同的类型，您可以阅读以下内容：

/unix/170493/login-non-login-and-interactive-non-interactive-shells

现在，如果您打开bashrc，将在开始时看到以下内容：

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

这意味着根据您访问系统的方式，此文件是否在其中加载代码。