
secure shell protocol简称SSH,是由IETF网络工作小组(network working group) 制定,在进行数据传输之前, SSH先对联级数据包通过加密技术进行加密处理,加密后在进行数据传输,确保了传递的数据安全.
SSH是 专门为远程登录会话和其他网络服务(例如:rsync,ansible)提供的安全性协议 ,利用SSH协议可以有效的防止远程管理过程中的信息泄露问题,绝大多数企业普遍采用SSH协议服务来代替传统的不安全的远程连接服务器软件(例如:Telnet/23端口/非加密的)等.
然后开始输入用户名
右击选中追踪流,在右侧再选中TCP流
即可显示数据包的全过程,圈中的部分是用户名,之所以每个单词重复出现,是因为数据有请求,有确认,所以会重复,去重以后就是用户名:shuai,密码:123456
在显示 yes/no 的时候,如果输入的 yes 就接收到了服务端发送过来的公钥信息,把这个信息放到了 /root/.ssh/known_hosts文件 里
SSH服务由服务端软件 OpenSSH(Openssl) 和客户端 常见的有SSH(linux),secureCRT,putty,Xshell 组成.SSH服务默认使用22端口提供服务, 他有两个不兼容的SSH协议版本,分别是1.x和2.x
如果在进行连接的时候出现以下情况,如何解决
基于口令的安全验证方式就是知道服务器的SSH连接账号和口令(也要知道对应服务器的IP地址及开放的SSH端口,默认为22端口)就可以通过SSH客户端登录到远程主机上面,此时联机过程中所有传输的数据都是加密的!
- 演示XSHELL及SSH客户端连接,口令验证测试
基于密钥的安全验证方式是指,需要依靠密钥,也就是必须事先建立一对密钥对,然后把 公用密钥(锁头:public key) 放在需要访问的目标服务器上,另外,还需要把 私有密钥(钥匙:private key) 放到SSH的客户端或对应的客户端服务器上.
此时,如果想要连接到这个带有公用密钥的SSH服务器上,客户端SSH软件或者客户端服务器就会向SSH服务器发出请求,请用联机的用户密钥进行安全验证,SSH服务器收到请求之后,会先在该SSH服务器上连接的用户的家目录下面寻找事先放上去的对应用户的公用密钥,然后把它和连接SSH客户端发送过来的公用密钥进行比较,如果两个密钥一直,SSH服务器就用公用密钥加密"质询(challenge)"并把它发送给SSH客户端!
SSH客户端收到"质询"之后就可以用自己的私钥解密,在把它发送给SSH服务器,使用这种方式,需要知道联机用户的密钥文件,与第一种基于口令验证的方式相比,第二种方式不需要在网络上传送口令密码,所以安全性更高了,这是我们也注意保护我们的密钥文件,特别是私钥文件,一旦被黑获取到,危险系数增大很多.
修改SSH服务的运行参数,是通过修改配置文件 /etc/ssh/sshd_config 来实现的.
一般来说SSH服务使用默认的配置已经能够很好的工作了,如果对安全要求不高,仅仅提供SSH服务的情况,可以不需要修改任何参数配置.
SSH服务监听参数说明
企业服务器被入侵案例
拉取:PULL
参考:http://blog.csdn.net/jia0511/article/details/8237698
1. 允许root用户远程登录
修改ssh服务配置文件
sudovi/etc/ssh/sshd_config
调整PermitRootLogin参数值为yes,如下图:
2. 允许无密码登录
同上,修改ssh服务配置文件,两种情况:
1) 将PermitEmptyPasswords yes前面的#号去掉
2) 将PermitEmptyPasswords 参数值修改为yes,如下图:
无论哪种,最后PermitEmptyPasswords参数值为yes
以上两种配置,均需要重启ssh服务
service sshd restart # 或者/etc/initd.d/sshd restart
扩展:
为了安全起见,FreeBSD默认情况下是不允许root用户进行SSH远程登录的,需要进行以下 *** 作才可以进行Root用户的ssh远程登录。
首先vi编辑/etc/inetd.conf,去掉ssh前的#注释,保存后:wq退出 (开启监听ssh服务)
编辑/etc/rc.conf, 最后加入:sshd_enable=”yes”即可
激活sshd服务:
#/etc/rc.d/sshd start
检查服务是否启动,在22端口应该有监听。
# check port number22
#netstat -an #或
#netstat -tnlp
最后,编辑ssh配置文件
#vi/etc/ssh/sshd_config
在/etc/ssh/sshd_config最后中加入
PermitRootLogin yes #允许root登录
PermitEmptyPasswords no #不允许空密码登录
PasswordAuthentication yes # 设置是否使用口令验证。
修改完配置文件后,重新启动sshd服务器(/etc/rc.d/sshd restart)即可。
补充:
1. 如果重启后还是不行, 请重新载入sshd_config 文件
/etc/rc.d/sshd reload
2. 如果出现using keyboard-interactive authentication
password:
请确认配置文件中,PasswordAuthentication参数值是否已经改成yes
另外如果客户端是putty, 那么请确认”尝试’智能键盘’认证(SSH-2)”的勾是否有去掉!!!!
3. 如果是使用root帐号登陆
请确认密码是否为空
空密码无法登陆
4. 请确认是否有安装SSH
确认sysinstall>>>configure>>>networking>>>sshd是否的勾是否有打上.
最近在编写脚本的时候发现一个问题,在执行 kubectl -n kube-system get pods 这个命令的时候,通过 ssh root@ip command 和 ssh root@ip command 登录后执行得到了不同的结果,
从上面可以看到SSH远程执行获取pods失败了,但是shell窗口执行却成功了,所以我们可以猜到两者之间一定有什么区别导致结果的不同。那么区别在哪里呢?通过研究发现两者的环境变量存在区别,通过执行printenv可以查看所有设置的环境变量:
通过上面可以看到SSH远程执行的时候是没有KUBECONFIG这个环境变量,而Shell窗口是有的,为什么有这个区别呢?这就要从Linux的bash的四种模式说起。
bash的四种模式:
从上面可以看出不同方式下加载的配置文件不同,那么怎么知道我们是加载了那些配置文件呢? 这里有一个验证的方法,就是在上面的每个配置文件中添加一句 echo $/etc/profile 这样的命令,把每个文件的路径打印出来。当配置文件被加载时,会输出相应的文件名,本例中在两个文件中加了该命令:/etc/pfoile, ~/.bashrc,然后使用不同SSH方式执行命令的结果如下。
只加载了.bashrc文件,未加载/etc/profile。
从输出可以看到两个配置都加载了,而KUBECONFIG只定义在/etc/profile中,没有定义在.bashrc文件中,所以通过 ssh root@ip command 执行时没有拿到KUBECONFIG这个环境变量从而导致报错。知道原因后我们就可以将KUBECONFIG环境变量添加到.bashrc文件即可。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)