如何无视跳板机?

2013-07-26 22:11:49 +08:00
 lequiet
公司连上远程游戏服需要先ssh登到跳板机,再在跳板机上ssh到远程,不能直连,如:
自己的系统(Mac OS) ===> 跳板机 ===>远程服务器

1. 跳板机和远程服务器是Linux,远程服务器有python 2.5(太旧了)
都有ssh、scp,但远程服务器不能用ssh、scp连到跳板机。跳板机不能用ssh和scp连到自己的
系统。也就是说只能正向不能反向。
2. 自己的系统有perl 5.1、python 2.7.5、ssh、scp等各种UNIX必备。
3. 跳板机能用的命令不多,能访问的目录只有自己的home目录。
4. 远程服务器有运维监控着,不能乱搞乱开监听端口开服务。

困难
====
现在的效率比较低的是,有很多的批量可以做的事,比如在N台服务器执行一样的一系列命令,
传文件N个这些服务器,从N个服务器拉特定的日志文件等,因为隔着一台跳板机,不能很轻易的
在自己的系统上搞个脚本自动执行这些重复繁琐的任务。

目前的解决方案
==========
secureCRT脚本。
用secureCRT的Session会话可以一键点击连到远程服务器,secureCRT脚本还可以调用这些预建好的Session自动打开Session然后做跑一些命令(并能自动输入密码)。
但是有时候用得很吃力,有时要打开远程服务器的Session去做,有时如果涉及多个远程的Session,为了不打开太多,就用跳板机的Session用ssh连各个服务器执行各个远程服务器的命令。
传文件也是,比如上传一个文件,secureCRT脚本要执行本地的scp传到跳板机,然后打开跳板机的Session,执行scp拷到远程服务器。

虽然已经封装好了很多函数,用起来比较方便了,但还是免不了打开这个那个Session,在这个那个Session里执行各种命令的状况。

所以想简化这个过程,“绕过”这个跳板机。在本地写脚本,能操作到远程的服务器并执行一些命令。(既然跳板机可以ssh命令到远程服务器执行一个命令就收工,那本地系统上可以用ssh命令到跳板机执行 [前面那段ssh到远程服务器执行命令的命令] ?但这貌似有点复杂,尤其是两次都要输密码,甚至执行的命令本身也要输密码并且又考虑安全的情况下)

寻找解决方法
==========
网上找到了fabric和(R)?ex, 前者是Python实现的,后者是perl实现的。但貌似两者只有在“直连"服务器时才能用,猜测也是在实现了ssh命令的连上某服务器执行命令的功能基础上做了封装。

貌似ssh有本地端口转发,但不太会用,不知能不能结合上fabric或者Rex,在不在跳板机和远程服务器作太多“手脚”的情况下,完成本地和远程方便的交互。
17396 次点击
所在节点    程序员
62 条回复
xofyarg
2013-08-05 10:29:18 +08:00
“这根本不是技术问题啊,而是规则问题,如果你觉得这个规则不爽,那你可以提出来,否则就好好遵守,要不然你就跳槽到别的公司干。” 赞同。

是否可以考虑在跳板机后找一台机器作为开发机,自己安装一些常用的软件。然后可以使用这台开发机连接其他服务器。跳板机的目的就是分离办公环境和生产环境。如果能够绕道进去,说明安全建设还不到位。 :)
xderam
2013-08-05 11:36:40 +08:00
@xofyarg 感觉楼主这个需求应该是在办公环境和生产环境中间,少了一个和生产环境的测试环境才萌发的。
hfcorriez
2013-08-05 11:39:27 +08:00
snnn
2013-08-05 13:51:47 +08:00
ssh -D5800 tiaoban -NTf

然后让scp和securecrt走5800这个socks proxy即可。
lequiet
2013-08-09 00:09:35 +08:00
@xderam 运维有运维的流程和规范,比如他们坚决不给你用rz,但在此种情形下我们总不能老敲长长的scp吧,而且是两次,而且都要密码,而且不同target用户名密码都不同。这种情形写个脚本自动scp两次自动输密码让我们少花很多在“运维”上的事。
lequiet
2013-08-09 00:26:19 +08:00
@xofyarg 哪台开发机能连(远程)服务器不是我们能决定的。公司的办公环境跟开发环境是一样的,都是内网。需要跳板机也许是远程服务器安全需要不想那么多可以连进去(远程服务器并不是公司一起维护的),或者公司安全需求跟本不想让内网机能直接连出去而是让跳板机多一层监控。@xderam 测试环境(也就是能直连的内部服务器)也有的,但只限于开发测试。由于网游的运营需要,经常需要线上操作,
lequiet
2013-08-09 00:27:18 +08:00
@hfcorriez 多谢,看标题就是我需要的了哈
xderam
2013-08-09 11:17:07 +08:00
@lequiet 呃,”经常需要线上操作”。。这个。。呵呵。。作为一个SA其实我想表达的是沟通应该比纯技术解决问题来的更彻底和直接一些。
xofyarg
2013-08-09 14:51:46 +08:00
@lequiet 我的意思是建议你在跳板机后面找一台机器作为开发机,这样就可以不用折腾这个问题了。当然,对于有些不是特别在意安全的公司来说,跳板机还是比较容易穿越的。
bjzhush
2013-08-09 15:03:19 +08:00
研发和运维的战争
lequiet
2013-08-09 21:00:04 +08:00
@xderam 作为一个小角色表示跟本就没有权力和能力和机会去说服运维改变现有的规则,而且规则也不一定是在做事的运维想改能改的。本贴原意在于讨论脚本、自动化任务,即便没有跳板机,也有可以参考学习的回复。所谓“无视”,也并没有无视鄙视这个种规则和机制的意思。
lequiet
2013-08-09 21:05:29 +08:00
@xofyarg 在意安全是肯定的,穿越跳板机(如果可以的话)被抓到估计不止被fire这么简单。本帖所说的远程服务器,是指线上运营中用的服务器,也正是经常需要到上面去操作的服务器,反倒内网的直连的开发测试服务器压根没有脚本自动化的需求。
zxp
2013-08-09 21:42:28 +08:00
跳板机上screen or tmux 连上目标服务器,只detach不logout,以后只需要连上跳板机就已经在目标服务器上了。
lequiet
2013-08-09 23:31:58 +08:00
@zxp 什么原理?
zxp
2013-08-10 08:19:48 +08:00
参考 /t/73262 或在本站搜索tmux或screen
xderam
2013-08-14 14:48:43 +08:00
@bjzhush 持续交付里想避免的就是这种战争,可惜大多数人都想通过技术绕过研发和运维的那个墙,而不是沟通和交流。作为一个运维,我赶脚不能让开发的同学舒服是运维的失职。
fatpa
2013-08-14 17:26:15 +08:00
pssh 估计可以帮到你~
bjzhush
2013-08-19 17:30:44 +08:00
@xderam 有些时候,并不完全是两个部门的事,公司要抓安全,所以运维就暴力地在路由封掉了exe的下载,公司不允许听歌看视频,又疯掉了mp3/flv,有时候,他们也是奉命行事,而且我喜欢技术斗争,随他封掉,我再想办法绕过,这也挺好玩的
plprapper
2013-08-19 19:04:18 +08:00
https://code.google.com/p/parallel-ssh/ 你大概需要的是这个吧
lequiet
2015-08-13 13:36:44 +08:00
挖旧贴两年后回复:
@pubby @arbeitandy 当时是用的第二方案解决了问题,第三方案没试。远程server们是有做IP限制的,只限从跳板server ip登录。

实现的具体方式:
用Python写个通用的同步脚本,内部调用的就是@pubby 列的那些端口映射ssh命令然后再rsync/scp命令完成目录、文件同步、命令执行,用pexpect模块完成需要密码时的交互。脚本在本地Mac(UNIX命令环境)上执行,不同服务器密码用对称加密的方式(然并卵骗骗自己觉得稍微安全点吧)存在$HOME目录的一个ini文件里。 实际上只有少部分的远程服务器还在用密码其余已是证书,连跳板机也自己改用了证书。

@xdays Fabric当时没看到这功能,一开始尝试用的是perl的Rex,连接远程服务器前先跟跳板机建ssh proxy,跟你说的Fabric的gateway方案应该是一样的。后来觉得用得不爽就自己用Python实现了。

@xofyarg 跳板机后面找一台机器作为开发机,这个听起来行得通但服务开发人员这么多,不能大家都用那个开发机进行开发吧(大家都登录到那台server,用vim写代码?),如果只是拿那个开发server作为分发前的测试和中转,那本地PC跟这台跳板机后的开发机server的同步问题就又绕回来了。

不用理会我,就是说一下后续而已:
@xderam @peterlu
线上机器的权限已回收,改文件的权限也没了,不用也不能做这种事了。安全和效率是要运维一开始就考虑好的,比如很久前其它部门有研发用SecureCRT脚本以方便登录跳转到指定服务器,密码都在里面,全体研发大家一起用,而这脚本还是运维帮写的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/77090

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX