简单点 使用这个命令 手动执行下看看报错是啥呢 
是tiup自己创建的
是的，tiup是部署在hcicloud用户下边的，公司方面实施都习惯性将服务部署在这个用户，在扩容的时候，使用-uroot 指定使用目标机的root用户操作，是为了用最高权限操作，一直都是通过root用户登录中控机，然后su - hcicloud 进行的tiup操作，去掉-user也试过，他会直接在目标机上使用hcicloud扩容，但是权限不足，以及之前的节点/tmp 文件权限会有问题
这个也尝试过了，中控机和目标机都 已经调整成20000了，还是报错
手工通过ssh root@192.168.1.160 ，然后执行命令是正常执行的，没有报错反馈，现在的问题变成tiup创建目录的时候，可以正常创建 tidb-deploy，但是第二层的 pd-2379创建失败，文件也没有复制进去
预期情况就是用部署 tiup 的用户去操作 tiup ，如果权限不足就先解决权限的问题呢？
你这用户有点乱啊， 一会 root ，一会 hcicloud ，还有 tidb 用户。。
额。。。我梳理一下哈，中控机服务器是 192.168.1.62 ，tiup部署的用户是hcicloud， 需要扩容的目标机器是 192.168.1.160，扩容的时候指定使用root用户操作，tidb用户是tiup自己创建的
你还用clicloud用户扩容，对应的权限有关的报错是什么呢？ 按照报错把权限赋好也不行吗？
因为集群内已经有部署成功的节点了，他在check的时候，会把包传到/tmp/tiup目录，之前的这个目录权限是root权限，因为不确定这个目录变更会不会对现有的集群产生影响，还有就是目前这个tcp报错，感觉和用哪个用户没有太大的关系，官网中提示是需要拥有最高权限的用户来操作目标服务器呢？
[quote=“TiDBer_fh6uzCEK, post:1, topic:1037415”]
我猜一下：
已经尝试过通过中控机扩容其他的服务器，可以正常操作，那这应该就是这一台不能扩容的机器的问题，
如果其他机器之前可以扩容，现在不能了，那说明应该是中控的问题
我也不知道是不是之前调整ssh配置把环境搞乱了，现在在已经扩容过的机器上也没办法正常扩容了，现在的问题主要是确认是哪一块的配置出了问题
在 ~/.tiup/storage/cluster/clusters/<cluster_name>/ssh 目录下有一个 id_rsa ,你用 ssh -i 的方式用这个密钥试试看能不能ssh 到对应的要扩容的节点上
可以的，基本上都在目标机器中配置过公钥了
检查一下目标端主机的 /var/log/messages 日志呢，看看有没有清理 ssh 连接的内容；同时也检查一下 sshd 服务有没有重启的记录。
这个也检查过，没有明显的报错等信息，会不会是网络丢包？这种情况该怎么排查