ssh 管理 linux登录远程服务器

使用 ssh 免秘登录方式

 

（还可以使用 ssh-agent 缓存密码）

 

客户端：
1. 生成公钥和私钥

ssh-keygen

一般不需要对私钥设置口令（passphrase），如果担心私钥的安全，这里可以设置一个。

运行结束以后，在$HOME/.ssh/目录下，会新生成两个文件：id_rsa.pub和id_rsa

 

2.将公钥传送到远程主机 host上面

ssh-copy-id user@host -p port

附：复制到剪切板，可以粘贴到 github 的方法

$ sudo apt-get install xclip
# Downloads and installs xclip. If you don't have `apt-get`, you might need to use another installer (like `yum`)

$ xclip -sel clip < ~/.ssh/id_rsa.pub
# Copies the contents of the id_rsa.pub file to your clipboard

 

3.配置 ssh 连接信息

vim $HOME/.ssh/config

写入相关参数

Host host1
HostName 198.93.47.225
User root
Port 22
IdentityFile ~/.ssh/id_rsa

编辑该文件权限

chmod 600 $HOME/.ssh/config

 

4.就 ssh信息添加到代理中

ssh-add

 

5.登录

ssh host1

 

6.利用 scp传输文件

scp -P 22 /home/lg/Documents/Project/PycharmProjects/GroupBot/abc.ini host1:/root

 

7.sftp 传输文件

$ sftp host1
sftp> get Documents/1.txt /home/lg/Documents/

 

ssh 原理

1.生成一对公钥与私钥对（可以在客户端直接生成，也可以在其它地方生成）

ssh-keygen

2,客户端配置该私钥存放路径

Host book
HostName 139.97.102.212
User root
Port 22
IdentityFile ~/.ssh/book_solr.pem

 3.服务器配置该公钥的内容保存到 ~/.ssh/authorized_keys 文件中

ssh-copy-id user@host -p port

4.前三步配置好了之后，客户端向服务器第一次发请求，会返回服务端的公钥并要求你确定。确定后，客户端拿到该公钥并保存到 know_hosts 中（可设置 StrictHostKeyChecking=no，会自动添加，不必手动确认）。

 

5.安全保证

公钥的两层作用（数据加密与验证签名）

数据加密：客户端向服务器发送信息（使用服务端公钥加密）；服务器向客户端发送信息（使用客户端公钥加密的）。

1）密钥与算法协商阶段：

会话密钥的交换：

① 服务端将服务端公钥发送给客户端。

② 服务端生成会话ID ，设为 id ，发送给客户端。

③ 客户端生成会话密钥，设为 key ，并计算 res = id 异或 key。

④ 客户端将 res 用服务端公钥进行加密，将结果发送给服务端。

⑤ 服务端用服务端私钥进行解密，得到 res。

⑥ 服务器计算 res 异或 id，得到 key。 至此服务端和客户端都知道了会话密钥和会话ID，以后的数据传输都使用会话密钥进行加密和解密。

2）认证阶段：

服务端对客户端进行认证：
① 客户端使用密钥和算法协商阶段生成的会话密钥加密账号、认证方法、id_dsa.pub，将结果发送给服务端。
② 服务端使用会话密钥解密报文，得到账号、id_rsa.pub。 服务端在这个账号的目录的.ssh目录下找对应的公钥，如果没有找到，发送失败消息给客户端，如果找到，比较客户发送过来的这个公钥和找到的公钥，如果内容相同，服务端生成一个随机的字符串，简称“质询”，然后使用找到的公钥加密这个质询，然后使用会话密钥再次加密。（质询的基本原理：用公钥加密的内容，只有对应的私钥才能解密。对于服务端来说，如果能客户端解密出来就证明客户端的来源是合法的）
④ 服务端把这个双重加密的数据发送给客户端。
⑤ 客户端使用会话密钥解密报文，然后使用id_rsa再次解密数据，得到质询。
⑥ 客户端使用会话密钥加密质询，发送给服务端。
⑦ 服务端使用会话密钥解密报文，得到质询，判断是不是自己生成的那个质询，如果不相同，发送失败消息给客户端，如果相同，认证通过。

 

验证签名：HTTPS 安全保证

参看

基本原理是服务器向ca机构申请一个https证书，该证书包含公钥与私钥；服务器将公钥发给客户端，客户端向服务器发送使用公钥加密的一个随机数，服务端收到随机数后以此随机数作为对称加密算法的密钥与客户端互相传递消息。详细过程是：客户端向服务端发送请求，服务端发送一个由CA私钥签名过的HTTPS证书的公钥给客户端（浏览器点击地址栏的https证书设置可以将证书公钥导出），客户端用CA提供的公钥去解密，获取这个公钥的签名信息，验证这段公钥包含的签名信息中的域名是不是所请求的服务端。如果是，则客户端生成一个随机字符串sessionKey，并用服务端给的公钥加密这段随机字符串，并发送给服务端。服务端用CA签发的证书的私钥去解密 sessionKey，后续用这个共有的 sessionKey 进行对称加密，互相发送内容。

这个原理的关键点是CA分发了一个由CA私钥加密的包含服务端域名的签名的公钥文件，这样的签名是没法被中间人篡改的（因为中间人无法获取CA的私钥），并且这个公钥文件的签名只能通过CA的公钥去解密，而CA的公钥是被信任的（操作系统预装的CA公钥），也就确保了后续操作的安全性。而我们在使用fiddler等相关软件时，我们需要导入fiddler的证书作为CA证书，这样前面提到CA加密的公钥文件就被替换了。

 

总结：

1）公钥加密的数据只能由私钥解密，通过“质询”可以确保私钥的来源合法。

2）公钥只能解对应私钥的签名，用其它的私钥无法构造对应的签名。对于判断文件是否被中间人修改来说，由于签名是公开的，中间人可以使用旧文件的签名拼接到新文件，将无法判断该文件是否已经修改。因此，对于文件防篡改来说，签名中需要包含文件的摘要。对于更改后的文件，由于摘要不一样，故无法将旧文件的签名拼接到新文件，而新的签名必须得拥有私钥的人才能签，从而防止了文件被中间人篡改。

 

注：

1）随便什么人都可以加密（公钥是公开的），但只有拥有对应私钥的人才能解密。

2）随便什么人都可以签名（别人也可以有他们自己的私钥），但公钥是已知的，只有该公钥相对应的私钥的签名才能被解析。

 

2333