☰

我正在 X11 环境中执行 plink (ssh) → sudo → 远程文件复制，但失败

tag-icon • tag-icon ssh networking x11 remote authentication
我正在 X11 环境中执行 plink (ssh) → sudo → 远程文件复制，但失败

我是 Linux 新手，所以我可能有点不熟悉这里使用的术语，但我现在尝试做的是在 Windows PC 上，我将使用 plink ssh 进入 Linux 服务器并使用sudo以下命令运行另一个用户将文件从远程位置复制到本地。例如，

从 Windows 机器 A： plink [email protected] "sudo -u user_a python /tools/copyfile.py remoteserverC.com:/a/b/c/filetocopy.txt /local/targetfile.txt"

  • 其中 linuxserverB 和 RemoteserverC 都是 Linux
  • python脚本将接受2个参数并调用scp进行复制，第一个是源，下一个是要复制的目标

我会得到Disconnected: Protocol error (Too many authentication failures for user_a). Child process (ssh) exited with code 78)

我注意到一些事情：

  1. 如果我使用 plink 执行相同的调用，但源和目标更改为仅复制/localTo '/local/',(linuxserverB ) 中的文件，则不会有问题。仅当我尝试像原始示例一样从 remoteserverC.com 访问文件时才会发生这种情况。

  2. 我尝试在另一台 Linux 机器（Linux D）上使用与 ssh 相同的命令而不是 plink，并进行详细转储，我发现我会得到几乎相同的错误：

    X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
..
Unable to open display linuxserverB.com:123.0 Disconnected. Protocol error (Too many authentication failures for user_a)
  3. 所以我认为这可能是由于X11转发问题造成的，尽管我对这个概念不太熟悉。基本上我尝试使用-X并plink会得到： 
    Putty X11 proxy: wrong authorisation protocol attemptedUnable to open display linuxserverB.com:123.0 ... Disconnected: Protocol error (Too many authentication failures for user_a)

  4. 我尝试xauth在remoteserverC.com 和linuxserverB.com 上添加显示，以便remoteserverC.com 和linuxserverB.com 包含彼此的显示ID，但问题仍然存在。

  5. 我还尝试在 Windows 机器 A 上安装 XMing，并且能够xeyes成功执行 plink。

所以我不太确定出了什么问题。还有其他我可以尝试的事情吗？该问题是由于 X11 转发显示位置还是由于.XAuthority问题造成的？

答案1

是的，该消息似乎来自remoteserverC。

您正在使用 plink 连接到testadminlinuxserverB 并在那里运行脚本sudo -u user_a。因此该脚本将作为user_a@linuxserverB.

由于 scp 目标规范不包括用户名，因此 perl 脚本中嵌入的 scp 命令将尝试连接到user_a@remoteserverC.显然，要么用户名错误，要么没有适当的密钥（或者有更多的连接上可用的密钥比远程服务器允许的身份验证尝试次数C)。

第一个问题是，user_a@remoteserverC有道理吗？如果user_a在remoteserverC 上不存在，则您的复制源规范需要包含remoteserverC 的用户名，例如[email protected]:/a/b/c/filetocopy.txt。

如果这不能解决问题，请检查 RemoteserverC 上的日志并找出哪种身份验证尝试被拒绝以及原因。也许用户的~/.ssh/authorized_keys文件在 RemoteserverC 上没有得到充分的保护，因此服务器的sshd守护进程忽略了授权密钥列表。该authorized_keys文件需要受到保护，以便只有用户本身（或 root）可以对其进行写入。如果是这种情况，日志消息应指示其权限sshd不满意的文件或目录。

相关内容