加密 https ssh

本文介绍了对称加密和非对称加密的基本概念,包括常用的加密算法,如DES、3DES、AES等对称加密算法,以及RSA、Elgamal等非对称加密算法。此外还详细阐述了HTTPS、SSH等协议中公钥和私钥的具体应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

对称加密

同一个密钥可以同时用作信息的加密和解密,这种加密方法称为对称加密

在对称加密算法中常用的算法有:DES3DES、TDEA、Blowfish、RC2、RC4、RC5IDEA、SKIPJACK、AES等

 

非对称加密

非对称加密算法需要两个密钥来进行加密和解密,这两个秘钥是公开密钥(public key,简称公钥)和私有密钥(private key,简称私钥)

在非对称加密中使用的主要算法有:RSAElgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等

 

https

  1. 客户端向服务器发起请求
  2. 服务器向客户端发送数字证书
  3. 客户端通过CA的公钥验证数字证书的签名是否由CA发布
  4. 客户端生成随机字符串,发送给服务器
  5. 服务器用公钥对该字符串做数字签名,并发送给客户端
  6. 客户端用证书上的公钥验证该数字签名
  7. 服务器也可要求验证客户端的数字证书

客户端验证公钥过程:

htts链接时,服务器向客户端发送公钥,和CA用私钥加密的公钥。

客户端,通过CA的公钥解密服务器传来的加密公钥证书

 

ssh

ssh user@host

四、口令登录

整个过程是这样的:(1)远程主机收到用户的登录请求,把自己的公钥发给用户。(2)用户使用这个公钥,将登录密码加密后,发送回来。(3)远程主机用自己的私钥,解密登录密码,如果密码正确,就同意用户登录

 

五、公钥登录

所谓"公钥登录",原理很简单,就是用户将自己的公钥储存在远程主机上。登录的时候,远程主机会向用户发送一段随机字符串,用户用自己的私钥加密后,再发回来。远程主机用事先储存的公钥进行解密,如果成功,就证明用户是可信的,直接允许登录shell,不再要求密码。

<think>好的,我现在需要回答用户关于HTTPSSSH和GitHub CLI的问题。首先,我得确保自己对这些概念有准确的理解,然后按照用户的要求组织信息。 首先,HTTPSSSH都是用于与GitHub等远程仓库通信的协议。HTTPS可能更容易设置,尤其是对于新手,因为它通常不需要生成密钥对,但每次推送可能需要输入凭证。而SSH则使用密钥对验证,更安全且方便,但需要用户生成并管理密钥。这点需要解释清楚两者的区别和使用场景。 然后是GitHub CLI,这是一个命令行工具,允许用户直接在终端中与GitHub交互,比如管理仓库、处理PR等。需要说明它的功能和优势,比如提高工作效率,避免频繁切换界面。 接下来,要确保遵循系统级指令。所有的行内数学表达式用$...$,但这里可能用不上数学公式,不过如果有涉及版本号或命令中的变量,可能需要用代码格式。但用户提到的是HTTPSSSH和GitHub CLI,所以可能更多的是命令示例,比如git clone或者gh repo create这样的命令。不过用户特别指出要使用LaTeX格式的行内数学表达式,可能需要检查是否有相关的内容需要用到,但看起来这些主题可能不涉及数学公式。不过要留意,如果有任何技术术语或代码,可能需要用正确的格式,比如代码块或者行内代码,但用户要求的是LaTeX数学表达式,这里可能需要确认是否有必要的地方应用。 用户要求结构清晰,分步骤解释。可能需要将每个主题分开介绍,比较HTTPSSSH的区别,然后介绍GitHub CLI的功能。同时,要使用中文回答,保持口语化,但避免使用Markdown格式。 需要检查是否有任何技术细节错误。例如,HTTPS是否需要用户名和密码,或者现在是否推荐使用令牌代替密码,这一点需要确认。GitHub已经停用了对密码的支持,改为使用个人访问令牌(PAT),所以在HTTPS克隆时需要提供令牌作为密码。这一点需要准确说明,避免误导用户。 关于SSH,用户需要生成SSH密钥对,并将公钥添加到GitHub账户。这部分步骤可能需要简要提及,但用户可能不需要详细的操作指南,除非问题中有提到。但根据用户的问题,只是要求介绍,所以可能不需要深入步骤,但需要说明基本流程。 GitHub CLI部分,需要介绍常用命令,比如gh repo clone, gh pr create等,说明其便利性。同时,可以提到它如何简化工作流程,比如问题管理、拉取请求处理等。 最后,总结三者之间的关系,比如GitHub CLI可以使用HTTPSSSH进行仓库操作,而选择协议取决于用户需求。需要确保信息准确,没有遗漏重要点。 现在需要组织这些内容,按照用户的指示分点回答,结构清晰。可能需要分为三个主要部分:HTTPSSSH、GitHub CLI,每个部分下分点介绍,然后比较HTTPSSSH的优缺点,最后说明GitHub CLI的作用。</think>以下是关于 **HTTPS**、**SSH** 和 **GitHub CLI** 的详细介绍,分步说明它们的功能、区别和使用场景: --- ### 1. HTTPS(超文本传输安全协议) - **定义**:HTTPS 是 HTTP 的安全版本,通过 SSL/TLS 协议对通信进行加密,确保数据传输的机密性和完整性。 - **在 GitHub 中的应用**: - **克隆仓库**:使用 `git clone https://github.com/用户名/仓库名.git`。 - **身份验证**:早期需输入 GitHub 用户名和密码,现需使用**个人访问令牌(PAT)**替代密码。 - **优点**: - 配置简单,无需生成密钥。 - 适合防火墙限制严格的环境(因使用 443 端口)。 - **缺点**: - 每次推送代码需输入凭证(除非配置凭据缓存)。 --- ### 2. SSH(安全外壳协议) - **定义**:SSH 是一种加密网络协议,通过密钥对(公钥+私钥)实现身份验证和加密通信。 - **在 GitHub 中的应用**: - **克隆仓库**:使用 `git clone git@github.com:用户名/仓库名.git`。 - **身份验证**:需预先生成 SSH 密钥对,并将公钥添加到 GitHub 账户。 - **优点**: - 免密操作(一次配置,长期有效)。 - 安全性更高(基于非对称加密)。 - **缺点**: - 需手动管理密钥对。 - 可能受网络策略限制(使用 22 端口)。 --- ### 3. GitHub CLI - **定义**:GitHub 官方命令行工具(命令为 `gh`),支持直接在终端中管理 GitHub 资源。 - **核心功能**: - **仓库操作**:`gh repo create`(新建仓库)、`gh repo clone`(克隆仓库)。 - **问题管理**:`gh issue list`(查看问题)、`gh issue create`(提交问题)。 - **拉取请求**:`gh pr create`(创建 PR)、`gh pr checkout`(切换至 PR 分支)。 - **无缝集成**:支持通过 HTTPSSSH 协议操作仓库。 - **优点**: - 简化开发流程,避免频繁切换至网页端。 - 支持脚本化操作,适合自动化任务。 --- ### 对比 HTTPS vs SSH | 特性 | HTTPS | SSH | |--------------|------------------------------------|------------------------------------| | **身份验证** | 用户名 + 个人访问令牌(PAT) | 密钥对(公钥 + 私钥) | | **端口** | 443 | 22 | | **便捷性** | 需重复输入凭证(除非缓存) | 一次配置,长期有效 | | **适用场景** | 临时使用或简单项目 | 长期开发或团队协作 | --- ### 总结 - **HTTPS/SSH**:是与 GitHub 仓库交互的两种协议,选择取决于安全需求和使用习惯。 - **GitHub CLI**:提升效率的工具,可配合 HTTPSSSH 使用,适合习惯终端操作的开发者。 如需进一步操作指导(如生成 SSH 密钥或安装 GitHub CLI),可随时补充提问!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值