Question

我开发了几个Fabric脚本，可以自动在Jelastic环境中部署我的Web应用程序。这些脚本每次都运行良好，直到今天。这个问题让我感到困惑，因为自上次成功执行以来，我的脚本和环境都没有变化;唯一值得注意的变化是我的Jelastic提供商（ServNet Mexico）现在正在运行Jelastic平台的4.9版本。

我的当地环境：

Windows 10
Python 2.7
Fabric 1.13.1（最新版本，我今天升级后，看它是否有任何区别）
Paramiko 2.1.1（由PIP安装为Fabric依赖）

我在另外两台机器上遇到了完全相同的问题，包括MacOS Sierra和等效的Python和Fabric设置，但使用旧版本的Fabric软件包（及其依赖项），几天前工作得很好。

在Fabric之外，通过PuTTY（在Windows上）和终端（MacOS）的SSH访问正常工作。最近发生的一件事是，在远程会话开始时会显示一个身份验证标志（警告SSH访问的危险，如下所示）。我怀疑这与我的问题有什么关系。

根据建议by this troubleshooting page on the Fabric documentation，我为fab命令启用了--show = debug标志，并为Paramiko启用了日志。我的命令窗口上的输出看起来像这样（我省略了一些可以被视为私有和敏感的行，据我所知，这些行不提供手头问题的相关信息）：

Command line prompt>fab --show=debug my_task
Using fabfile '<path_to_fabric_script>'
Commands to run: my_task
Parallel tasks now using pool size of 0
<sensitive information omitted>
Parallel tasks now using pool size of 10
<sensitive information omitted>
[<jelastic_node>] run: /bin/bash -l -c "cd /var/lib/jelastic/backup && rm -f <file_to_delete>"
DEBUG:paramiko.transport:starting thread (client mode): 0x3cd61d0L
DEBUG:paramiko.transport:Local version/idstring: SSH-2.0-paramiko_2.1.1
DEBUG:paramiko.transport:Remote version/idstring: SSH-2.0-JSSHProxy
INFO:paramiko.transport:Connected (version 2.0, client JSSHProxy)
DEBUG:paramiko.transport:kex algos:[u'ecdh-sha2-nistp256', u'ecdh-sha2-nistp384', u'ecdh-sha2-nistp521', u'diffie-hellman-group14-sha1', u'diffie-hellman-group1-sha1'] server key:[u'ssh-rsa'] client encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'aes128-gcm@openssh.com', u'arcfour256', u'arcfour128'] server encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'aes128-gcm@openssh.com', u'arcfour256', u'arcfour128'] client mac:[u'hmac-sha1', u'hmac-sha1-96'] server mac:[u'hmac-sha1', u'hmac-sha1-96'] client compress:[u'none'] server compress:[u'none'] client lang:[u''] server lang:[u''] kex follows?False
DEBUG:paramiko.transport:Kex agreed: diffie-hellman-group1-sha1
DEBUG:paramiko.transport:Cipher agreed: aes128-ctr
DEBUG:paramiko.transport:MAC agreed: hmac-sha1-96
DEBUG:paramiko.transport:Compression agreed: none
DEBUG:paramiko.transport:kex engine KexGroup1 specified hash_algo <built-in function openssl_sha1>
DEBUG:paramiko.transport:Switch to new keys ...
DEBUG:paramiko.transport:Adding ssh-rsa host key for [gate.jl.serv.net.mx]:3022: <key>
DEBUG:paramiko.transport:Trying SSH agent key <key>
DEBUG:paramiko.transport:userauth is OK
INFO:paramiko.transport:Auth banner:
  Welcome to Jelastic shell

  This shell will assist you in managing Jelastic applications.

    ============================== ATTENTION ==============================
   Shell access is rather powerful and you can accidentally damage your application.
   So please pay special attention to the actions you perform here.
    ============================== ATTENTION ==============================



INFO:paramiko.transport:Authentication (publickey) successful!
DEBUG:paramiko.transport:[chan 0] Max packet in: 32768 bytes
DEBUG:paramiko.transport:[chan 0] Max packet out: 32768 bytes
DEBUG:paramiko.transport:Secsh channel 0 opened.
DEBUG:paramiko.transport:[chan 0] Sesch channel 0 request ok

Fabric任务就在那时挂起。没有进一步的输出，没有任何成功或失败的消息，没有超时，没有任何可能发生的事情的迹象。 Fabric任务的命令本身也不运行，因为Fabric任务所针对的Jelastic节点没有产生预期的效果（我最简单的任务就是用rm命令删除一些备份文件;其他任务我开发的更精细，他们也不会运行。）

我倾向于认为此问题与新的（4.9）Jelastic版本或其在Jelastic提供商的基础架构上的特定部署有关。不幸的是，当我向他们寻求有关此事的帮助时，我的提供者没有帮助。

我很欣赏有关可能发生的事情的任何线索。

Answer 1

您可以尝试使用选项--keepalive = 5..10

进行连接

Answer 2

这可能是paramico lib的问题，您可以查看问题here。

Answer 3

由ssh welcome banner的错误处理引起的这种行为。但我们有一个解决方法：编辑/ etc / ssh / sshd_config并注释以下行：

Banner /etc/jmotd

然后，重新启动sshd守护程序：

service sshd restart

如果您遇到任何困难，请随时通过support@jelastic.com与我们联系。

致以最诚挚的问候， Jelastic支持团队

用于自动Web应用程序部署的Fabric脚本不再适用于Jelastic版本4.9

3 个答案: