SSH forwarding

来源：http://gl08301.blog.163.com/blog/static/132118851201121732552784/

ssh -L [bind_address:]port:host:hostport <ssh hostname>

-L 选项即是指本地端口转发。其中的host:hostport指定的是由<ssh hostname>转发的数据的目标主机地址及端口，该目的地址可以与<ssh hostname>相同。意即本机（假设为debian）将会建立一条到<ssh hostname>的ssh连接。同时将到本机的[bind_address:]port的连接转发到本机与<ssh hostname>之间的ssh连接，即将这两个连接做衔接处理。同样的，在<ssh hostname>端，会建立一条到host:hostport的ssh连接，并将之前与debian建立的ssh连接与host:hostport的连接做衔接处理。

三台主机 debian redhat oracle IP地址分别为 192.168.0.10{0,1,2}
on redhat : use the command 
ssh -g -L 192.168.0.101:4444:192.168.0.102:22 root@192.168.0.102
该命令建立一个到 oracle的ssh连接，socket为192.168.0.101:48332------192.168.0.102:22，

on debian
use the command
ssh root@192.168.0.101 -p 4444
need input the root password on 192.168.0.101, but 之前 login to with ssh on the listen port （我在配置文件里面定义的ssh 的服务端口），didn't need password，because I use 公钥认证, not password 认证，but after I change to connect to  the port 4444, I should give the password.

输入密码连接之后，登录到的是192.168.0.102而非192.168.0.101.
使用who命令检查，显示的居然是从本地的192.168.0.102登录的，而非我之前预期的192.168.0.101，看来是命令
ssh -g -L 192.168.0.101:4444:192.168.0.102:22 root@192.168.0.102中指定的192.168.0.102在起作用。
在192.168.0.102上使用netstate命令检查，发现多了一对192.168.0.102:22-----192.168.0.102:46086的socket

其中的流程是，debian发起一条到redhat上的4444端口的ssh连接，redhat在debian通过验证后，允建立对192.168.0.100:48918-----192.168.0.101:4444的socket。redhat在192.168.0.100:48918-----192.168.0.101:4444与192.168.0.101:48332------192.168.0.102:22之间做端口转发，redhat(192.168.0.101)要求oracle(192.168.0.102)建立一条到192.168.0.102:22(在这里是oracleb本身，实际可以是其它主机)的ssh连接,并将该连接与192.168.0.101:48332------192.168.0.102:22做衔接处理。于是在192.168.0.102上看，会发现有一条从192.168.0.102而非192.168.0.101登录的用户

当我在debian上退出ssh连接时，发现在oracle上面的(local)192.168.0.102:46086-----(foreign)192.168.0.102:22的连接处于wait状态，之前的
(local)192.168.0.102:22-----(foreign)192.168.0.102:46086消失了。不太明白local和foreign的角色分配为何如此？而当我重新执行ssh root@192.168.0.101 -p 4444 时，发现那条处于wait状态的连接的本地端口发生了改变，变成了(local)192.168.0.102:46086-----(foreign)192.168.0.102:22，不知何故？

远程转发 ssh  -R [bind_address:]port:host:hostport <ssh hostname>
在debian上使用以下命令
ssh -p 35 -R 22:192.168.0.102:22 root@192.168.0.101
含义是首先以root身份建立一条到192.168.0.101(redhat)的ssh连接（这里由于我设置的192.168.0.101上面的ssh的监听端口为35，所以加上了-p参数，否则不需要-p参数。但是如果22号端口是ssh服务的监听端口，则 port ，转发远端数据到 ssh 通道的那个端口不能为22了，因为到这个端口的连接就不会被转发了）。同时要求192.168.0.101监听自己的22号端口，将到该端口的连接与已建立的到192.168.0.100的ssh连接做衔接处理，将到自己的22号端口的数据转发给debian,而192.168.0.100（即debian）将会将从192.168.0.101转发过来的数据再转发给192.168.0.102的22号端口。(但是只属于redhat和debian之间的通信不会被转发，所以仍旧可以在debian上对redhat进行控制，返回来的数据不会被转发到192.168.0.102。这应该是被区分开了吧)
接着我在redhat上面使用
ssh 127.0.0.1   #注意，由于之前的命令没有指定bind_address，此时只能使用loopback接口
虽然在redhat上面的ssh服务本来并不监听22号端口，但是这次却没有拒绝连接，但是要求加入127.0.0.1的公钥到knowhosts,连接成功后发现登录的是192.168.0.102，
在192.168.0.102上查看，登录的用户来自192.168.0.100（debian）
退出时，应该先断掉后建立的连接（因为它依赖之前建立的连接），再断掉第一命令建立的连接


NB. 如果指定了bind_address同时<ssh hostname>启用了GatewayPorts option（相当于 -g option），就可以将其它主机到<ssh hostname>的22号端口的连接进行转发
我退出所有连接后，将ssh -p 35 -R 22:192.168.0.102:22 root@192.168.0.101更改为
ssh -p 35 -R 192.168.0.101:22:192.168.0.102:22 root@192.168.0.101
然后再从debian上登录redhat的22端口，结果却由于端口转发之后，收到的密钥不是redhat的，ssh客户端不让连接，切换到root用户，并清空其known_host文件，使用ssh 192.168.0.102，显示收到的密钥与之前 ssh 192.168.0.101相同，证实了我的判断，之前收到的密钥是oracle的。再返回使用 ssh 192.168.0.101，登录之后发现登录的是192.168.0.102.