linux-ssh加密与https安全-9

非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

hash就是找到一种数据内容和数据存放地址之间的映射关系
（1) 文件校验
有奇偶校验和CRC校验，这2种校验并没有抗数据篡改的能力，它们一定程度上能检测并纠正数据传输中的信道误码，但却不能防止对数据的恶意破
MD5 Hash算法的"数字指纹"特性，应用最广泛的一种文件完整性校验和(Checksum)算法，不少Unix系统有提供计算md5 checksum的命令
（2) 数字签名
 Hash 值，又称"数字摘要" 进行数字签名
其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

为什么需要https

http存在三个弊端：
1）无法保证消息的保密性；
2）无法保证消息的完整性和准确性；
3）无法保证消息来源的可靠性。

对称加密（共享密匙加密）

客户端和服务器公用一个密匙用来对消息加解密，这种方式称为对称加密。客户端和服务器约定好一个加密的密匙。客户端在发消息前用该密匙对消息加密，发送给服务器后，服务器再用该密匙进行解密拿到消息

    对称加密的优点：对称加密解决了http中消息保密性的问题
    对称加密的缺点：对称加密虽然保证了消息保密性，但是因为客户端和服务器共享一个密匙，这样就使得密匙特别容易泄露。
    因为密匙泄露风险较高，所以很难保证消息来源的可靠性、消息的完整性和准确性。

非对称加密（公有密匙加密）

采用非对称加密时，客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙可以对外暴露，而私有密匙只有自己可见。
使用公有密匙加密的消息，只有对应的私有密匙才能解开。反过来，使用私有密匙加密的消息，只有公有密匙才能解开。这样客户端在发送消息前，先用服务器的公匙对消息进行加密，服务器收到后再用自己的私匙进行解密。

非对称加密的优点：
1）非对称加密采用公有密匙和私有密匙的方式，解决了http中消息保密性问题，而且使得私有密匙泄露的风险降低；
2）因为公匙加密的消息只有对应的私匙才能解开，所以较大程度上保证了消息的来源性以及消息的准确性和完整性。
非对称加密的缺点：

1）非对称加密时需要使用到接收方的公匙对消息进行加密，但是公匙不是保密的，任何人都可以拿到，中间人也可以。那么中间人可以做两件事，第一件是中间人可以在客户端与服务器交换公匙的时候，将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的，而是服务器的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙，但是他可以截获客户端发来的消息，然后篡改，然后用服务器的公匙加密再发往服务器，服务器将收到错误的消息；
2）非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。

数字签名
为了解决非对称加密中公匙来源的不安全性。我们可以使用数字证书和数字签名来解决

扫描二维码关注公众号，回复： 7421486 查看本文章

有一些专门的权威机构用来颁发数字证书，我们称这些机构为认证中心（CA Certificate Authority）

证书的签发(Signing)和认证(Verification)的过程

签发证书的步骤：

1. Signing阶段，首先撰写证书的元信息：签发人(Issuer)、地址、签发时间、过期失效等；当然，这些信息中还包含证书持有者(owner)的基本信息，例如owner的DN(DNS Name，即证书生效的域名)，owner的公钥等基本信息。
2. 通过通用的Hash算法将信息摘要提取出来；
3. Hash摘要通过Issuer(CA)私钥进行非对称加密，生成一个签名密文；
4. 将签名密文attach到文件证书上，使之变成一个签名过的证书。
   验证证书的步骤：
5. Verification阶段，浏览器获得之前签发的证书；
6. 将其解压后分别获得“元数据”和“签名密文”；
7. 将同样的Hash算法应用到“元数据”获取摘要；
8. 将密文通过Issuer(CA)的公钥（非对称算法，私钥加密，公钥解密）解密获得同样的摘要值。
9. 比对两个摘要，如果匹配，则说明这个证书是被CA验证过合法证书，里面的公钥等信息是可信的。

证书有3类：

1. end-user ：baidu.com 包含用来加密传输数据的公钥的证书，是HTTPS中使用的证书
2. intermediates：CA用来认证公钥持有者身份的证书，即确认HTTPS使用的end-user证书是属于baidu.com的证书。这类intermediates证书甚至可以有很多级。
3. root：用来认证intermediates证书是合法证书的证书。

除了end-user之外，证书被分为root Certificates和intermediates Certificates。相应地，CA也分了两种类型：root CAs 和 intermediates CAs。首先，CA的组织结构是一个树结构，一个root CAs下面包含多个intermediates CAs，而intermediates又可以包含多个intermediates CAs。root CAs 和 intermediates CAs都可以颁发证书给用户，颁发的证书分别是root Certificates和intermediates Certificates，最终用户用来认证公钥的证书则被称为end-user Certificates

使用end-user certificates来确保加密传输数据的公钥(public key)不被篡改，而又如何确保end-user certificates的合法性呢？这个认证过程跟公钥的认证过程类似，首先获取颁布end-user certificates的CA的证书，然后验证end-user certificates的signature。一般来说，root CAs不会直接颁布end-user certificates的，而是授权给多个二级CA，而二级CA又可以授权给多个三级CA，这些中间的CA就是intermediates CAs，它们才会颁布end-user certificates

证书链生成

https://sg.godaddy.com/help/nginx-on-centos-7-install-a-certificate-27192

CA

CA（Certificate Authority）证书颁发机构主要负责证书的颁发、管理以及归档和吊销。证书内包含了拥有证书者的姓名、地址、电子邮件帐号、公钥、证书有效期、发放证书的CA、CA的数字签名等信息。证书主要有三大功能：加密、签名、身份验证

SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：
　　①客户端的浏览器向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
　　②服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
　　③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
　　④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
　　⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
　　⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码 ”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
　　⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
　　⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
　　⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
　　⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。
https://www----wosign.com/faq/faq2016-0309-04.htm

ssh 端口转发

端口转发
能够将其他 TCP 端口的网络数据通过 SSH 链接来转发，并且自动提供了相应的加密及解密服务。这一过程有时也被叫做“隧道”（tunneling）
如果工作环境中的防火墙限制了一些网络端口的使用，但是允许 SSH 的连接，那么也是能够通过将 TCP 端口转发来使用 SSH 进行通讯。
SSH 端口转发能够提供两大功能：

1. 加密 SSH Client 端至 SSH Server 端之间的通讯数据。
2. 突破防火墙的限制完成一些之前无法建立的 TCP 连接。

本地转发

ssh -L 7001:localhost:389 LdapServerHost
localhost 指server，取决于服务器的访问要求

  sshclient    无法通过其他端口连接server，可以通过server端口转发解决
   
  注意：在client  配置。
   1，SSH 端口转发是通过 SSH 连接建立起来的，我们必须保持这个 SSH 连接以使端口转发保持生效。一旦关闭了此连接，相应的端口转发也会随之关闭
   2，只能在建立 SSH 连接的同时创建端口转发，而不能给一个已经存在的 SSH 连接增加端口转发
   3，只能进行本地端口转发，即只有client可以，其他不能通过 client主机访问他的端口
   可以通过指定它与其他机器共享这个本地端口转发。
   ssh -g -L <local port>:<remote host>:<remote port> <SSH hostname>
   
   数据流方式：
   • 我们在 LdapClientHost 上的应用将数据发送到本机的 7001 端口上，
    • 而本机的 SSH Client 会将 7001 端口收到的数据加密并转发到 LdapServertHost 的 SSH Server 上。
    • SSH Server 会解密收到的数据并将之转发到监听的 LDAP 389 端口上，
    • 最后再将从 LDAP 返回的数据原路返回以完成整个流程

远程转发
由于网络或防火墙的原因我们不能用 SSH 直接从 LdapClientHost 连接到 LDAP 服务器（LdapServertHost），但是反向连接却是被允许的。那此时我们的选择自然就是远程端口转发
ssh -R 7001:localhost:389 LdapClientHost

在 LDAP 服务器（LdapServertHost）端执行如下命令：
ssh -R 7001:localhost:389 LdapClientHost

远程转发时：
LdapClientHost 是应用的客户端，但却是 SSH Server ；而 LdapServertHost 是 LDAP 的服务端，但却是 SSH Client 

数据流：
在 LdapClientHost 上的应用将数据发送到本机的 7001 端口上，而本机的 SSH Server 会将 7001 端口收到的数据加密并转发到 LdapServertHost 的 SSH Client 上。 SSH Client 会解密收到的数据并将之转发到监听的 LDAP 389 端口上，最后再将从 LDAP 返回的数据原路返回以完成整个流程
https 流程

https://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/index.html

动态端口转发：
内网A主机无法上网，需要通过跳板机B上网，在A配置
ssh -D 端口 B

1）客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密匙长度等）；
2）服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的；
3）服务器发送证书报文。报文中包含公开密匙证书；
4）最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束；
5）SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密匙进行加密；

7）客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准；
8）服务器同样发送Change Cipher Spec报文；
9）服务器同样发送Finished报文；
10）服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会收到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求；
11）应用层协议通信，即发送HTTP相应；
12）最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信
在以上流程图中，应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保证报文的完整性。

ssh服务登陆验证

known_hosts

ssh把每个访问过计算机的公钥(public key)都记录在~/.ssh/known_hosts。当下次访问相同计算机时，OpenSSH会核对公钥。如果公钥不同，OpenSSH会发出警告， 避免你受到DNS Hijack之类的攻击
authorized_keys

 基于用户口令
     
 1 客户端发起ssh请求，服务器会把自己的公钥发送给用户
 2 用户会根据服务器发来的公钥对密码进行加密
 3 加密后的信息回传给服务器，服务器用自己的私钥解密，如果密码正确，则用户登录成功

  基于密钥登陆
  1 首先在客户端生成一对密钥（ssh-keygen）
  2 并将客户端的公钥ssh-copy-id 拷贝到服务端
  3 当客户端再次发送一个连接请求，包括ip、用户名
  4 服务端得到客户端的请求后，会到authorized_keys中查找，如果有相应的IP和用户，就会随机生成一个字符串，例如：magedu
  5 服务端将使用客户端拷贝过来的公钥进行加密，然后发送给客户端
  6 得到服务端发来的消息后，客户端会使用私钥进行解密，然后将解密后的字符串发送给服务端
  7服务端接受到客户端发来的字符串后，跟之前的字符串进行对比，如果一致，就允许免密码登录

ssh sudo AIDE TCP_awra ppers

基于KEY验证实现方法
基于密钥的认证：
(1) 在客户端生成密钥对ssh-keygen -t rsa [-P ''] [-f “~/.ssh/id_rsa"]
(2) 把公钥文件传输至远程服务器对应用户的家目录ssh-copy-id [-i [identity_file]] [user@]host
此步骤将客户端的公钥添加至远端服务器的authorized_keys 文件中
(3) 测试
(4) 在SecureCRT或Xshell实现基于key验证

生成密钥
[ ! -e ~/.ssh/id_rsa ] && ( ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa &> /dev/null ) || echo "you already had id_rsa"

ssh优化

修改端口，默认监听ip,禁止root远程登陆

ListenAddress ip

ubunt 默认root无法远程登陆： PermitRootLogin prohbt-paswd 改为yes
MaxAuthTries 6
密码错误的次数6/2=3(MAN帮助中写明要除2)次后断开连接

MaxSessions 10 每个链接最大session数 是指通过复制ssh渠道产生会话连接的， ss -nt查看远端端口一样，即没有产生新的ssh连接端口
GatewayPorts no 端口转发 ，其他主机也可使用本机端口进行连接
ClientAliveCountMax 默认3

ClientAliveInterval 10

ClientAliveCountMax 0 10s不操作，自动断开

ssh连接速度加快
UseDNS no
GSSAPIAuthentication yes 提高速度可改为no

MaxStartups 10:30:60 允许10个未验证连接（已连接未输入密码）
安全策略
找出登陆失败的IP awk '/Failed password/{print $(NF-3)}' /var/log/secure

限制可登录用户
监听特定IP地址，使用密钥，禁止root用户登陆， 限制ssh 访问频度，并发在线数

分析日志

SUDO
配置文件：/etc/sudoers, /etc/sudoers.d/
日志文件：/var/log/secure
visudo -c 检查语法visudo -f /etc/sudoers.d/test test为自定义文件

配置文件支持使用通配符glob
? 任意单一字符

• 匹配任意长度字符
  [wxc] 匹配其中一个字符
  [!wxc] 除了这三个字符的其它字符
  \x 转义
  [[alpha]] 字母 示例： /bin/ls [[alpha]]*

规则

root ALL=（ALL） ALL

user: 运行命令者的身份
host: 通过哪些主机
(runas)：以哪个用户的身份
command: 运行哪些命令

s -l /usr/bin/sudo
sudo –i –u wang 切换身份
sudo [-u user] COMMAND
-V 显示版本信息等配置信息
-u user 默认为root-l,ll 列出用户在主机上可用的和被禁止的命令
-v 再延长密码有效期限5分钟,更新时间戳
-k 清除时间戳（1970-01-01），下次需要重新输密码
-K 与-k类似，还要删除时间戳文件
-b 在后台执行指令
-p 改变询问密码的提示符号 示例：-p ”password on %h for user %p:

AIDE 入侵检测

yum install aide

配置文件
vim /etc/aide.conf (指定对哪些文件进行检测)
/test/chameleon R
/bin/ps R+a
/usr/bin/crontab R+a
/etc PERMS!/etc/mtab #“!”表示忽略这个文件的检查
R=p+i+n+u+g+s+m+c+md5 权限+索引节点+链接数+用户+组+大小+最后一次修改时间+创建时间+md5校验值
NORMAL = R+rmd60+sha256

初始化
初始化默认的AIDE的库：/usr/local/bin/aide --init

生成检查数据库（建议初始数据库存放到安全的地方）
cd /var/lib/aidemv aide.db.new.gz aide.db.gz

检测：/usr/local/bin/aide --check
更新数据库aide --update

tcp_wrappers

工作在第四层（传输层）的TCP协议
对有状态连接的特定服务进行安全检测并实现访问控制
以库文件形式实现
某进程是否接受libwrap的控制取决于发起此进程的程序在编译时是否针对libwrap进行编译

 判断程序是否支持 tcp_wrapper进行访问控制的方法
 ldd /PATH/TO/PROGRAM|grep libwrap.so
 strings PATH/TO/PROGRAM|grep libwrap.so
  
  ldd `which  sshd`  | grep   libwrap

配置文件：/etc/hosts.allow, /etc/hosts.deny 
  检查顺序：hosts.allow，hosts.deny（默认允许）
  
  daemon_list@host: client_list [ :options :option… ]
  
  Daemon_list@host格式
  单个应用程序的二进制文件名，而非服务名，例如vsftpd
  以逗号或空格分隔的应用程序文件名列表，如:sshd,vsftpd
  ALL表示所有接受tcp_wrapper控制的服务程序
  主机有多个IP，可用@hostIP来实现控制如：[email protected]
   
  客户端Client_list格式 
 以逗号或空格分隔的客户端列表
 基于IP地址：192.168.10.1 192.168.1.
 基于主机名：www.magedu.com .magedu.com 较少用
 基于网络/掩码：192.168.0.0/255.255.255.0
 基于net/prefixlen: 192.168.1.0/24（CentOS7）
 基于网络组（NIS 域）：@mynetwork
 内置ACL：ALL，LOCAL，KNOWN，UNKNOWN，PARANOID
     
示例：

     vsftpd: 172.16. EXCEPT 172.16.100.0/24 EXCEPT 172.16.100.1  
   只允许192.168.1.0/24的主机访问sshd
   /etc/hosts.allow
            sshd: 192.168.1. 
   /etc/hosts.deny 
            sshd :ALL 
[:options]选项：     
     
  deny 主要用在/etc/hosts.allow定义“拒绝”规则
  如：vsftpd: 172.16. :deny
  allow 主要用在/etc/hosts.deny定义“允许”规则
  如：vsftpd:172.16. :allow
  spawn 启动一个外部程序完成执行的操作
  twist 实际动作是拒绝访问,使用指定操作替换当前服务,标准输出和ERROR发送到客户端,默认至/dev/null   
  测试工具：tcpdmatch [-d] daemon[@host] client-d 测试当前目录下的hosts.allow和hosts.deny   
     
     sshd: ALL :spawn echo "$(date +%%F) login attempt from %c to%s,%d" >>/var/log/sshd.log
     说明
      在/etc/hosts.allow中添加，允许登录，并记录日志
      在/etc/hosts.deny中添加，拒绝登录，并记录日志
      %c 客户端信息
      %s 服务器端信息
      %d 服务名
      %p 守护进程的PID
      %% 表示%
      vsftpd: 172.16. :twist /bin/echo “connection prohibited”
      
      PAM
      
      scp    
          scp [options] SRC... DEST/
          scp [options] [user@]host:/sourcefile /destpath
          scp [options] /sourcefile [user@]host:/destpath
       -C 压缩数据流
       -r 递归复制
       -p 保持原文件的属性信息
       -q 静默模式
       -P PORT 指明remote host的监听的端口
       
       rsync命令
       rsync -av /etc server1:/tmp 复制目录和目录下文件
       • rsync -av /etc/ server1:/tmp 只复制目录下文件
       
       常用选项：
       -n 模拟复制过程
       -v 显示详细过程
       -r 递归复制目录树
       -p 保留权限
       -t 保留时间戳
       -g 保留组信息
       -o 保留所有者信息
       -l 将软链接文件本身进行复制（默认）
       -L 将软链接文件指向的文件复制
       -a 存档，相当于–rlptgoD，但不保留ACL（-A）和SELinux属性（-X）

ssh 遇到的问题

问题描述，
A---- > B
A已经将公钥上传至B authorized_keys
A连接B时仍然需要密码

处理：
1，AB .ssh/ 下文件全部删除
2，A 重新生成公私钥，公钥上传至B并写入authorized_keys
3，检查B /etc/ssh/sshd.config
注释掉
PasswordAuthentication yes #放开后没有问题了，操

重新连接。

排查：

ssh -vT [email protected] 显式查看连接信息

查看 /root/.ssh/authorized_keys文件的属性，以及.ssh文件属性 是不是权限过大。.ssh目录的权限必须是700，同时本机的私钥的权限必须设置成600

查看 log/secure，分析问题在何处；检查/var/log/messages
修改/etc/ssh/sshd_config文件, 把密码认证关闭, 将认证改为 passwordAuthentication no 重启下sshd。 service sshd restart;

生成密钥

ssh-keygen -t rsa 产生 ./ssh/id_rsa.pub

在本目录下加载
ssh-add id_rsa
系统如果提示：Identity added: id_rsa (id_rsa) 就表明加载成功了
下面有几个异常情况处理：
–如果系统提示：could not open a connection to your authentication agent
则需要执行一下命令：
ssh-agent bash
然后再执行上述的ssh-add id_rsa命令
–如果系统提示id_rsa: No such file or directory
-这是系统无法找到私钥文件id_rsa，需要看看当前路径是不是不在.ssh目录，或者私钥文件改了名字，例如如果建立的时候改成 aa_rsa，则这边命令中也需要相应改一下
-如果系统提示 command not found，那肯定是你命令敲错字符了
-提示Agent admitted failure to sign using the key，私钥没有加载成功，重试ssh-add
-注意id_rsa/id_rsa.pub文件不要删除，存放在.ssh目录下

拷贝公钥到远端client ,文件内容写入 authorized_keys文件

etc/ssh/ssh_config:
Host
选项“Host”只对能够匹配后面字串的计算机有效。“”表示所有的计算机。
ForwardAgent no
“ForwardAgent”设置连接是否经过验证代理（如果存在）转发给远程计算机。
ForwardX11 no
“ForwardX11”设置X11连接是否被自动重定向到安全的通道和显示集（DISPLAY set）。
RhostsAuthentication no
“RhostsAuthentication”设置是否使用基于rhosts的安全验证。
RhostsRSAAuthentication no
“RhostsRSAAuthentication”设置是否使用用RSA算法的基于rhosts的安全验证。
RSAAuthentication yes
“RSAAuthentication”设置是否使用RSA算法进行安全验证。
PasswordAuthentication yes
“PasswordAuthentication”设置是否使用口令验证。
FallBackToRsh no
“FallBackToRsh”设置如果用ssh连接出现错误是否自动使用rsh。
UseRsh no
“UseRsh”设置是否在这台计算机上使用“rlogin/rsh”。
BatchMode no
“BatchMode”如果设为“yes”，passphrase/password（交互式输入口令）的提示将被禁止。当不能交互式输入口令的时候，这个选项对脚本文件和批处理任务十分有用。
CheckHostIP yes
“CheckHostIP”设置ssh是否查看连接到服务器的主机的IP地址以防止DNS欺骗。建议设置为“yes”。
StrictHostKeyChecking no
“StrictHostKeyChecking”如果设置成“yes”，ssh就不会自动把计算机的密匙加入“$HOME/.ssh/known_hosts”文件，并且一旦计算机的密匙发生了变化，就拒绝连接。
IdentityFile ~/.ssh/identity
“IdentityFile”设置从哪个文件读取用户的RSA安全验证标识。
Port 22
“Port”设置连接到远程主机的端口。
Cipher blowfish
“Cipher”设置加密用的密码。
EscapeChar ~
“EscapeChar”设置escape字符。

/etc/ssh/sshd_config:
Port 22
“Port”设置sshd监听的端口号。
ListenAddress 192.168.1.1
“ListenAddress”设置sshd服务器绑定的IP地址。
HostKey /etc/ssh/ssh_host_key
“HostKey”设置包含计算机私人密匙的文件。
ServerKeyBits 1024
“ServerKeyBits”定义服务器密匙的位数。
LoginGraceTime 600
“LoginGraceTime”设置如果用户不能成功登录，在切断连接之前服务器需要等待的时间（以秒为单位）。
KeyRegenerationInterval 3600
“KeyRegenerationInterval”设置在多少秒之后自动重新生成服务器的密匙（如果使用密匙）。重新生成密匙是为了防止用盗用的密匙解密被截获的信息。
PermitRootLogin no
“PermitRootLogin”设置root能不能用ssh登录。这个选项一定不要设成“yes”。
IgnoreRhosts yes
“IgnoreRhosts”设置验证的时候是否使用“rhosts”和“shosts”文件。
IgnoreUserKnownHosts yes
“IgnoreUserKnownHosts”设置ssh daemon是否在进行RhostsRSAAuthentication安全验证的时候忽略用户的“$HOME/.ssh/known_hosts”
StrictModes yes
“StrictModes”设置ssh在接收登录请求之前是否检查用户家目录和rhosts文件的权限和所有权。这通常是必要的，因为新手经常会把自己的目录和文件设成任何人都有写权限。
X11Forwarding no
“X11Forwarding”设置是否允许X11转发。
PrintMotd yes
“PrintMotd”设置sshd是否在用户登录的时候显示“/etc/motd”中的信息。
SyslogFacility AUTH
“SyslogFacility”设置在记录来自sshd的消息的时候，是否给出“facility code”。
LogLevel INFO
“LogLevel”设置记录sshd日志消息的层次。INFO是一个好的选择。查看sshd的man帮助页，已获取更多的信息。
RhostsAuthentication no
“RhostsAuthentication”设置只用rhosts或“/etc/hosts.equiv”进行安全验证是否已经足够了。
RhostsRSAAuthentication no
“RhostsRSA”设置是否允许用rhosts或“/etc/hosts.equiv”加上RSA进行安全验证。
RSAAuthentication yes
“RSAAuthentication”设置是否允许只有RSA安全验证。
PasswordAuthentication yes
“PasswordAuthentication”设置是否允许口令验证。
PermitEmptyPasswords no
“PermitEmptyPasswords”设置是否允许用口令为空的帐号登录。
AllowUsers admin
“AllowUsers”的后面可以跟着任意的数量的用户名的匹配串（patterns）或user@host这样的匹配串，这些字符串用空格隔开。主机名可以是DNS名或IP地址。

数字证书签发流程

认证机构如何是证书申请者本身，将获得自签名证书，客户端获取到证书后与服务器端通信

SSL/TLS协议分为两层：
记录协议:建立在可靠的传输协议之上，为高层协议提供数据封装、压缩、加密等基本功能的支持
握手协议:建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等

经过了SSL/TLS握手协议交互后，数据交互双方确定了本次会话使用的对称加密算法以及密钥，就可以开始进行加密数据交互了，以下是握手协议服务器端和客户端构建加密交互的相关流程图

、 随机数为后续构建密钥准备
2、 其他信息包括服务器证书、甚至包含获取客户端证书的请求

验证算法
如果服务器端回复客户端时带有其他信息，则进入数字证书验证阶段
客户端验证服务器端证书：

服务器端验证客户端证书

产生密钥
当服务器端和客户端经过上述流程后，就开始密钥构建交互了，服务器端和客户端最初需要主密钥为构建会话密钥做准备

会话密钥
完成上述主密钥构建操作后，服务器端和客户端将建立会话密钥，完成握手协议

加密交互
上述服务器端和客户端完成了握手协议以后就进入正式会话阶段，如果上述流程中有任何一端受到外界因素干扰发生异常，则重新进入协商算法阶段，下面流程表现进入会话阶段后，服务器端和客户端将使用会话密钥进行加密交互