如何建立本地SSH隧道
在我们计划建立一个本地SSH隧道之前,我们必须清楚下面这些数据:
中间服务器d的IP地址
要访问服务器c的IP地址
要访问服务器c的端口
现在,我们把上面这张图变得具体一些,给这些机器加上IP地址。并且根据下面这张图列出我们的计划:
需要访问234234234234的FTP服务,也就是端口21
中间服务器是123123123123
现在我们使用下面这条命令来达成我们的目的
ssh -N -f -L 2121:234234234234:21 123123123123
ftp localhost:2121 # 现在访问本地2121端口,就能连接234234234234的21端口了
这里我们用到了SSH客户端的三个参数,下面我们一一做出解释:
-N 告诉SSH客户端,这个连接不需要执行任何命令。仅仅做端口转发
-f 告诉SSH客户端在后台运行
-L 做本地映射端口,被冒号分割的三个部分含义分别是
需要使用的本地端口号
需要访问的目标机器IP地址(IP: 234234234234)
需要访问的目标机器端口(端口: 21)
最后一个参数是我们用来建立隧道的中间机器的IP地址(IP: 123123123123)
我们再重复一下-L参数的行为。-L X:Y:Z的含义是,将IP为Y的机器的Z端口通过中间服务器映射到本地机器的X端口。
在这条命令成功执行之后,我们已经具有绕过公司防火墙的能力,并且成功访问到了我们喜欢的一个FTP服务器了。
如何建立远程SSH隧道
通过建立本地SSH隧道,我们成功地绕过防火墙开始下载FTP上的资源了。那么当我们在家里的时候想要察看下载进度怎么办呢?大多数公司的网络是通过路由器接入互联网的,公司内部的机器不会直接与互联网连接,也就是不能通过互联网直接访问。通过线路D-B-A访问公司里的机器a便是不可能的。也许你已经注意到了,虽然D-B-A这个方向的连接不通,但是A-B-D这个方向的连接是没有问题的。那么,我们能否利用一条已经连接好的A-B-D方向的连接来完成D-B-A方向的访问呢?答案是肯定的,这就是远程SSH隧道的用途。
与本地SSH一样,我们在建立远程SSH隧道之前要清楚下面几个参数:
需要访问内部机器的远程机器的IP地址(这里是123123123123)
需要让远程机器能访问的内部机器的IP地址(这里因为是想把本机映射出去,因此IP是127001)
需要让远程机器能访问的内部机器的端口号(端口:22)
在清楚了上面的参数后,我们使用下面的命令来建立一个远程SSH隧道
ssh -N -f -R 2222:127001:22 123123123123
现在,在IP是123123123123的机器上我们用下面的命令就可以登陆公司的IP是1921680100的机器了。
ssh -p 2222 localhost
-N,-f 这两个参数我们已经在本地SSH隧道中介绍过了。我们现在重点说说参数-R。该参数的三个部分的含义分别是:
远程机器使用的端口(2222)
需要映射的内部机器的IP地址(127001)
需要映射的内部机器的端口(22)
例如:-R X:Y:Z 就是把我们内部的Y机器的Z端口映射到远程机器的X端口上。
建立SSH隧道的几个技巧
自动重连
隧道可能因为某些原因断开,例如:机器重启,长时间没有数据通信而被路由器切断等等。因此我们可以用程序控制隧道的重新连接,例如一个简单的循环或者使用 djb’s daemontools 不管用哪种方法,重连时都应避免因输入密码而卡死程序。关于如何安全的避免输入密码的方法,请参考我的 如何实现安全的免密码ssh登录 。这里请注意,如果通过其他程序控制隧道连接,应当避免将SSH客户端放到后台执行,也就是去掉-f参数。
保持长时间连接
有些路由器会把长时间没有通信的连接断开。SSH客户端的TCPKeepAlive选项可以避免这个问题的发生,默认情况下它是被开启的。如果它被关闭了,可以在ssh的命令上加上-o TCPKeepAlive=yes来开启。
另一种方法是,去掉-N参数,加入一个定期能产生输出的命令。例如: top或者vmstat。下面给出一个这种方法的例子:
ssh -R 2222:localhost:22 123123123123 "vmstat 30"
检查隧道状态
有些时候隧道会因为一些原因通信不畅而卡死,例如:由于传输数据量太大,被路由器带入stalled状态。这种时候,往往SSH客户端并不退出,而是卡死在那里。一种应对方法是,使用SSH客户端的ServerAliveInterval和ServerAliveCountMax选项。ServerAliveInterval会在隧道无通信后的一段设置好的时间后发送一个请求给服务器要求服务器响应。如果服务器在ServerAliveCountMax次请求后都没能响应,那么SSH客户端就自动断开连接并退出,将控制权交给你的监控程序。这两个选项的设置方法分别是在ssh时加入-o ServerAliveInterval=n和-o ServerAliveCountMax=m。其中n, m可以自行定义。
如何将端口绑定到外部地址上
使用上面的方法,映射的端口只能绑定在127001这个接口上。也就是说,只能被本机自己访问到。如何才能让其他机器访问这个端口呢?我们可以把这个映射的端口绑定在0000的接口上,方法是加上参数-b 0000。同时还需要打开SSH服务器端的一个选项-GatewayPorts。默认情况下它应当是被打开的。如果被关闭的话,可以在/etc/sshd_config中修改GatewayPorts no为GatewayPorts yes来打开它。
如何寻找中间服务器
如果你家里使用ADSL上网,多半你会比较幸运。一般的ADSL(例如 联通 的ADSL)都是有互联网地址的。你只需要在家里的路由器上一台装有OpenSSH server机器的SSH端口映射出去即可。同时一些提供SSH访问的虚拟主机也可以用于这一用途。例如: Hostmonser 或者 Dreamhost
通过SSH隧道建立SOCKS服务器
如果我们需要借助一台中间服务器访问很多资源,一个个映射显然不是高明的办法(事实上,高明确实没有用这个方法)。幸好,SSH客户端为我们提供了通过SSH隧道建立SOCKS服务器的功能。
通过下面的命令我们可以建立一个通过123123123123的SOCKS服务器。
ssh -N -f -D 1080 123123123 # 将端口绑定在127001上
ssh -N -f -D 0000:1080 123123123123 # 将端口绑定在0000上
通过SSH建立的SOCKS服务器使用的是SOCKS5协议,在为应用程序设置SOCKS代理的时候要特别注意。
总结
至此,我们已经对如何利用SSH隧道有一个基本的认识了。现在,文章开始时的那些问题应该迎刃而解了吧。这里要特别说一下,由于SSH隧道也使用了SSH加密协议,因此是不会被防火墙上的内容过滤器监控到的。也就是说一切在隧道中传输的数据都是被加密的。当然,离开隧道后的数据还是会保持自己原有的样子,没有加密的数据还是会被后续的路由设备监控到。在 《使用wireshark分析ssh口令登录细节》 和 《ssh工具,开发者必须有所了解》 这两篇文章中,我们知道了SSH登录有两种登录验证方式,其中口令登录方式使用简单,但会遇到安全问题,比如遇到中间人攻击,就会泄漏服务器的root口令。所以从安全的角度来看,建议使用另外一种登录验证方式,这就是密钥对登录方式。
密钥对验证方式对于初学者来说并不是很友好,所以我分两篇文章把这个事情说清楚,本文主要从原理的角度讲解,让你了解这种方式运作的流程,下一篇从实战的角度手把手教你登录ssh服务器。
对于开发者来说,也请务必学会使用密钥对方式登录服务器,因为现在很多应用和服务推荐这种方式,比如Github就可以使用密钥对方式连接,AWS默认就禁止口令登录。
网上有很多文章介绍ssh口令登录,但客观的说,很多文章讲错了。
很多人大概是这样理解的,客户端生成一个公开密码学算法的密钥对(注意不是ssh服务器端的密钥对),然后将公钥放到ssh服务器上的 authorized_keys 文件中(潜台词就是你有ssh权限才能 *** 作)。
然后ssh如何登录呢在连接过程中,会将客户端密钥对的公钥发送给ssh服务器,服务器在 authorized_keys 文件中匹配到这个公钥,就认为登录成功了,其实这个理解是有问题的。
核心的两个问题:
知道了这个结论后,我们看看详细的登录验证过程,在 《使用wireshark分析ssh口令登录细节》 中说过,ssh登录分为两个阶段,不管是哪一种登录验证,第一阶段的过程都是相同的,区别在于第二阶段。
有的同学说,这次你为啥不用wireshark分析了?因为第二阶段的消息传递都是加密保护的,并不能解密出具体的消息格式,这一点和TLS协议非常不同,TLS协议有多种方式可以解密出明文,而SSH协议是不支持的,所以wireshark只能显示密文。
基于这一点,本文就不用wireshark分析了,简单谈一谈ssh密钥对登录的流程,要经过多个消息交互。
第二阶段具体的流程如下:
1:ssh客户端生成一个 key ID(这个ID是基于密钥对的公钥算出来的,具体格式未知),再一次说明,这个密钥对不是服务器的,使用会话密钥加密后发送给服务器端。
2:服务器端从 authorized_keys 文件中匹配 key ID,如果匹配,此时还不能证明这个ssh客户端是真正的客户端密钥对的主人。
3:服务器端生成一个随机数,然后用客户端的公钥加密后发送给客户端。
4:客户端使用自己的私钥解密出服务器端的随机数,注意,如果某个攻击者仅仅有客户端的公钥,它是无法解密出的,因为攻击者没有对应的私钥。
5:为了向服务器端证明它能解密出这个随机数,客户端将解密出的随机数用会话密钥加密,将得到的值进行MD5运算。然后将这个值发送给服务器,以便响应(4)阶段的消息。
6:服务器端对原始随机数也使用会话密钥加密,再进行MD5计算,如果得出的值和(5)阶段客户端发送的一致,代表双方的登录校验通过。
服务器端使用服务器密钥对公钥指纹像客户端证明它就是真正的服务器端;而客户端使用它自己的密钥对向服务器证明它就是真实的客户端。
由于在验证过程中,客户端密钥对的公钥不会传输,所以即使遇到中间人攻击,攻击者也不会获取到公钥(不考虑客户端机器本身遇到攻击了)。
如果客户端的公钥曾经泄漏过,攻击者也不能成功登录ssh服务器,原因是攻击者没有私钥,无法解密出随机数,从而不能完成验证。
当然如果客户端密钥对公钥和私钥全部泄漏了,那就当我什么也没说,所以定期更换密钥对还是有好处的。
基于以上两点,我认为ssh密钥对登录是安全的,也是推荐的。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)