3分钟带你搞定SSH工作原理

深入理解SSH工作原理

说起Linux操作系统,对于做技术的人来说,没有不熟悉的;熟悉Linux的人那肯定都对SSH不陌生。ssh是一种用于安全访问远程服务器的协议,远程管理工具。它之所以集万身宠爱为一身,就是因为它的安全性。那么它到底是怎么样来保证安全的呢?

首先,在讲SSH是如何保证安全的之前,我们先来了解以下几个密码学相关概念:

对称加密算法(DES)

对称加密算法之DES.png
  1. Jack想要给Harry发送信息一个信息A,为了安全起见,Jack使用一种加密算法,比如给信息通过加一个数字B得到一个新的数字C,然后以公开的方式发送给Harry
  2. Harry接受到数字C后,通过减去一个数字B得到最终的真正的信息A
  3. Jack发送给Harry的信息A称为明文;加密后的信息C称为密文;加密用的B称之为密钥
  4. 加密算法(方法)可以很复杂,不一定是加和减,也可以是乘和除等等
  5. 以上过程中,加密和解密的秘钥是同一个密钥B

总结:

  1. 发送方使用密钥明文数据加密成密文,然后发送出去

  2. 接收方收到密文后,使用同一个密钥将密文解密成明文进行读取

非对称加密算法(RSA)

非对称加密之RSA.png
  1. 首先Harry生成一对有相互关系的密钥对,比如e(公钥)和f(私钥);其中公钥是可以公开给所有人的,私钥必须Harry本人私自留存,不得泄露。
  2. 当Jack发送请求时,Harry会把自己的公钥e发送给Jack
  3. Jack拿着Harry的公钥e通过一种加密算法将信息A加密成密文C,以公开的方式发送给Harry
  4. Harry收到密文C后,通过自己本地留存的私钥f将密文解密成最终的信息A
  5. 以上过程中,加密使用的是公钥e,解密使用的是私有f;使用不同的秘钥加解密

总结:

  1. 发送方使用接收方发送过来的公钥明文数据加密成密文,然后发送出去

  2. 接收方收到密文后,使用自己本地留存的私钥将密文解密成明文进行读取

  • 对称加密算法与非对称加密算法区别
    • 对称加密
      1. 使用同一个密钥进行加密和解密,密钥容易泄露
      2. 加密速度快,效率高,数据传输速度快,安全性较低
    • 非对称加密
      1. 使用不同的密钥(公钥和私钥)进行加密和解密
      2. 加密速度远远慢于对称加密,数据传输速度慢,安全性较高

SSH基于用户名密码认证

ssh远程基于用户认证访问过程.png
  1. SSH客户端向SSH服务端发起一个登录请求

  2. SSH服务端将自己的公钥发送给SSH客户端

    注意:如果是第一次访问,则提示以下内容:

    [root@MissHou ~]# ssh 192.168.10.171
    The authenticity of host '192.168.10.171 (192.168.10.171)' can't be established.     //无法确认主机192.168.10.171的真实性
    RSA key fingerprint is 9f:71:de:3c:86:25:dd:f0:06:78:ab:ba:96:5a:e4:95.
    Are you sure you want to continue connecting (yes/no)?yes
    说明:
    当客户端输入yes确认对方的公钥指纹后,server端的公钥就会被存放到客户机的用户家目录里~/.ssh/known_hosts文件中,下次再访问就直接通过密码登录,不需要再确认公钥。
    
  3. SSH客户端使用服务端发过来的公钥将自己的密码加密并且发送给SSH服务端

  4. SSH服务端收到SSH客户端发过来的加密密码后使用本地留存的私钥进行解密

  5. SSH服务端将解密出来的密码和/etc/shadow文件里的用户密码对比认证

  6. SSH服务端认证成功,则返回登录成功结果,并发送一个随机会话口令给客户端,该口令用于后面两台主机进行数据传输的一个临时加密会话口令

SSH基于密钥对认证

非对称加密.png

对比总结:

  • ssh远程登录两种认证方式
    • 基于用户名密码认证
      1. 用户身份认证(认证用户名和密码)使用非对称加密算法(安全)
      2. 数据传输使用对称加密算法(快)
      3. 要知道访问服务器用户的密码
    • 基于密钥对的认证(免密码)
      1. 用户身份认证(比对用户公钥)使用非对称加密算法(安全)
      2. 数据传输使用对称加密算法(快)
      3. 事先要将用户的公钥远程拷贝到服务器端

SSH免密码登录配置

环境介绍
node1:
10.1.1.250  用户:code1
node2:
10.1.1.1        用户:code
实际需求

node1主机上的code1用户免密码以code用户身份访问node2主机

操作步骤
  1. node1主机上的code1用户生成一对秘钥
[code1@node1 ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/code1/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/code1/.ssh/id_rsa.
Your public key has been saved in /home/code1/.ssh/id_rsa.pub.
The key fingerprint is:
73:5b:dc:96:43:4a:37:b3:98:8f:c4:39:3b:9b:3d:87 code1@jumper
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|            . =  |
|           + O = |
|        S . @ *  |
|         o + * . |
|          . + .. |
|             =E .|
|            o .o |
+-----------------+
[code1@node1 ~]$ cd .ssh/
[code1@node1 .ssh]$ ll
total 8
-rw------- 1 code1 coding 1671 Dec 30 21:44 id_rsa
-rw-r--r-- 1 code1 coding  394 Dec 30 21:44 id_rsa.pub
  1. node1上的code1用户将自己的公钥拷贝到node2端的code用户的家目录里
[code1@node1 .ssh]$ ssh-copy-id code@10.1.1.1
The authenticity of host '10.1.1.1 (10.1.1.1)' can't be established.
RSA key fingerprint is 30:c8:1a:67:55:22:33:26:e5:fb:44:56:4d:8b:26:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.1.1' (RSA) to the list of known hosts.
code@10.1.1.1's password: 
Now try logging into the machine, with "ssh 'code@10.1.1.1'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

3.测试验证

  1. 查看node2端的code用户家目录里的公钥存放文件
[code@node2 .ssh]$ cat authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApBfeaTY1PYpCKzOzpQzUzzAUqFKLdWyHTX2d6p3nLC4wXvh80pXyD3PTXjxkDYjfBP9+3h4HUnm7FTNiAHy79cTnDnDhfbKlYQcm3k6N4lu6H8ffhnitV0Yavxw8wfSQxK/khUybNU52370H8cfFn+msWK7hOweEYoQzliplBPmVR6FVeM+PkIZtvvMCN9TFL87XL6C6HJkMqgmyLNNtI334cYwQq3W619Y8kLl9l0/Vilp/WM97Akc/f1BkKIC4XveiRSVikzSM3Oh9gJV64rS2AdhtWeQN0DKGEYqX2OQTOdBmrIIZ4E7/NWWivesz9OjFsLUGRaohcuB/tMhbnw== code1@node1
  1. node1上的code1人员是否可以实现免密码登录node2
[code1@node1 ~]$ ssh code@10.1.1.1
Last login: Sat Dec 29 08:44:33 2018 from 10.1.1.250
[code@node2 ~]$ 

总结:

  1. 客户端用户生成一对秘钥(公钥和私钥)
  2. 将自己的公钥拷贝到远程主机的某个用户下面——>用户家目录里的authorized_keys
  3. 测试验证
相关文件解读
  1. id_rsa:私钥
  2. id_rsa.pub:公钥
  3. authorized_keys:保存已授权的客户端公钥
  4. known_hosts:保存已认证的远程主机公钥
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,951评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,606评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,601评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,478评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,565评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,587评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,590评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,337评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,785评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,096评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,273评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,935评论 5 339
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,578评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,199评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,440评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,163评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,133评论 2 352

推荐阅读更多精彩内容