做竞品分析的网站,巧克力网站建设需求分析,wordpress上面的模板,创意规划设计有限公司官网SCP的使用
背景介绍
最近项目是集群化部署#xff08;由 node1#xff0c;node2#xff0c;node3 三台 CentOS 7.4 的虚拟机构成#xff09;。
但是#xff0c;涉及到跨机器同步文件的问题#xff0c;想通过写shell文件实现#xff0c;用 crontab 设置定时任务#…SCP的使用
背景介绍
最近项目是集群化部署由 node1node2node3 三台 CentOS 7.4 的虚拟机构成。
但是涉及到跨机器同步文件的问题想通过写shell文件实现用 crontab 设置定时任务定时执行改脚本。
由于每次都需要输入密码导致定时任务没法正常工作因此需要三台机器之间可以免密码互相访问。 建立SSH的信任关系
以实现 node1 免密码给 node2 scp传输文件为例说明需要如下几个步骤
1、生成 node1 的秘钥私钥和公钥
1进入 node1 的 /root/.ssh 目录
cd /root/.ssh/2执行如下命令生成公钥和私钥此时一路回车即可
ssh-keygen -t rsa其中id_rsa 是私钥id_rsa.pub 是公钥。
2、将 node1 的 id_rsa.pub中的内容追加到 node2 的authorized_keys 认证文件中
1将 node1 的公钥id_rsa.pub信息输出到临时认证文件 authorized_keys_node1 中
cat id_rsa.pub authorized_keys_node12将 authorized_keys_node1 文件 scp 到 /root/.ssh/ 目录下
scp authorized_keys_node1 rootnode2:/root/.ssh/3登录到node2节点进入 /root/.ssh目录
cd /root/.ssh/4将 node1 的公钥信息追加到 node2 的认证文件authorized_keys中
cat authorized_keys_node1 authorized_keys至此node1 到 node2 的信任关系建立好了node1 scp文件到 node2就不在需要输入密码验证了。
其他机器之间的信任关系如有需要可以依此方法进行配置。
注意: 授权列表authorized_keys可以追加多台电脑的公钥(id_rsa.pub), 让多台电脑免密码验证 【额外说明】 1、上面用到了 Shell 的 和 因为使用场景不同。
如有不清楚二者异同点的同学可以参考博文https://blog.csdn.net/qq_43248623/article/details/107850758
2、文中提到的 id_rsa 和 id_rsa.pub 中的 rsa是指的 RSA加密算法。
RSA加密算法是一种非对称加密算法。在公开密钥加密和电子商业中RSA被广泛使用。RSA是1977年由罗纳德·李维斯特Ron Rivest、阿迪·萨莫尔Adi Shamir和伦纳德·阿德曼Leonard Adleman一起提出的。当时他们三人都在麻省理工学院工作。RSA就是他们三人姓氏开头字母拼在一起组成的。
对极大整数做因数分解的难度决定了RSA算法的可靠性。换言之对一极大整数做因数分解愈困难RSA算法愈可靠。假如有人找到一种快速因数分解的算法的话那么用RSA加密的信息的可靠性就肯定会极度下降。但找到这样的算法的可能性是非常小的。今天只有短的RSA钥匙才可能被强力方式解破。到目前为止世界上还没有任何可靠的攻击RSA算法的方式。只要其钥匙的长度足够长用RSA加密的信息实际上是不能被解破的。 详细解答部分:
预备知识 在介绍SCP协议之前我们先得了解一下SSH协议和计算机中的加密方式因为SCP协议的登录过程基于SSH协议。
对称加密 对称加密即在数据传输过程中对数据进行加密和解密的算法使用同一个密钥这种加密算法有什么弊端呢
当客户端需要与服务器端进行数据传输时不管是由客户端还是由服务端产生的密钥都得将这个密钥传给对方才能实现加解密而在传输的过程中就可能造成密钥的泄漏。
那么有些人就要说了那我不用网络传输秘钥我可以使用口头传输或者u盘拷贝的方法。
是的这样就可以保证安全但是在大多数互联网应用中通信双方是陌生设备无法做到上述的方式。
非对称加密 针对对称加密带来的风险非对称加密则解决了这个问题。
将加解密使用的密钥分为公钥和私钥公钥可以公开而私钥则由密钥生成者保存客户端使用公钥进行加密而服务端用私钥进行解密且目前来说还没有出现能从公钥推算出私钥的的破解机制。
所以相对于对称加密而言这种加密方式更加安全但是这种加密方式的缺点是会占用更多的计算机资源而且这种资源的耗费量是巨大的。
常见的加密方式 对称加密 DES(Data Encryption Standard):加密速度较快适合加密大量数据的场合。
3DES基于DES的加密算法顾名思义这是对一块数据用三个不同的密钥进行三次加密显而易见强度更高更安全。
RC2和RC4用变长密钥对大量数据进行加密速度比DES更快
IDEA:International Data Encryption Algorithm国际数据加密算法使用 128 位密钥提供非常强的安全性
AES:高级加密标准是下一代的加密算法标准速度快安全级别高这个加密算法被广泛应用。
非对称加密 RSA:是一个支持变长密钥的公共密钥算法需要加密的文件块的长度也是可变的目前使用最广的加密算法
Diff ieˉHellman每次交换数据的时候都使用一组新的密钥有效地防止了第三方获得私钥后解密所有信息但是同时对中间人攻击的防护比较薄弱。
非对称加密算法是一种密钥的保密方法。 非对称加密算法需要两个密钥公开密钥publickey:简称公钥和私有密钥privatekey:简称私钥。公钥与私钥是一对如果用公钥对数据进行加密只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥所以这种算法叫作非对称加密算法。 非对称加密算法实现机密信息交换的基本过程是甲方生成一对密钥并将公钥公开需要向甲方发送信息的其他角色(乙方)使用该密钥(甲方的公钥)对机密信息进行加密后再发送给甲方甲方再用自己私钥对加密后的信息进行解密。甲方想要回复乙方时正好相反使用乙方的公钥对数据进行加密同理乙方使用自己的私钥来进行解密。 另一方面甲方可以使用自己的私钥对机密信息进行签名后再发送给乙方乙方再用甲方的公钥对甲方发送回来的数据进行验签。 甲方只能用其私钥解密由其公钥加密后的任何信息。 非对称加密算法的保密性比较好它消除了最终用户交换密钥的需要。 非对称密码体制的特点算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快。对称密码体制中只有一种密钥并且是非公开的如果要解密就得让对方知道密钥。所以保证其安全性就是保证密钥的安全而非对称密钥体制有两种密钥其中一个是公开的这样就可以不需要像对称密码那样传输对方的密钥了。这样安全性就大了很多。 SSH协议 SSH是一种加密的网络传输协议可在不安全的网络中为网络服务提供安全的传输环境最常见的运用是远程登录。SSH的交互流程是这样的 客户端发送请求这个请求其实就是ssh登录请求即发起者拥有服务器上的某个用户的账号密码以远程登录的方式来操作服务器。 服务器将公钥发送给客户端这个公钥是给客户端进行数据加密用的 客户端收到服务器公钥确定是否继续连接为什么会有这么一个流程呢既然我指定了就是要连接服务器为什么还要让我确认一次,这会不会是多此一举呢其实不然这是为了防范中间人攻击。 客户端用公钥对密码进行加密再发送给服务器 服务器用私钥对密码进行解密返回登录结果
中间人攻击 刚刚提到中间人攻击我们就来看看什么是中间人攻击
我们大可以想一想在一个不安全的网络中如果我发送的请求被第三方截获而第三方把他的公钥发给我而我用他的公钥对密码进行加密然后再发送给他他就获得了完整的账号密码这时候他就可以拿着从我这儿窃取来的信息登录服务器。
那么在一个不安全的网络中我们该怎样防范这种攻击方式呢一般有两种方法 服务器将公钥公布在官方或者以其他方式公开让用户可以查到进行对比如果不匹配就在第三步的时候取消登录即可。 CA证书由一个权威机构CA对公钥进行认证CA机构的数字签名使得攻击者不能伪造和篡改证书。CA机构会为申请者发放一个公钥CA将该公钥和申请者的身份信息绑定在一起并为之签字。
如果一个用户想鉴别另一个证书的真伪他就用 CA 的公钥对那个证书上的签字进行验证一旦验证通过该证书就被认为是有效的。 SCP的传输 说回到SCP的传输SCP的传输第一步就是进行SSH的登录动作然后再基于SSH协议进行文件的传输整个传输过程是加密的。
在上面提到的ssh登录流程中是最基本的登录流程特点在登录时服务器要求客户端提供账号密码进行验证其实这样是非常麻烦的在每次登录或者传输文件时都要输入账号密码这对于以偷懒为终极目标的程序员来说这是不能忍受的。
SCP的免密传输 我们可以想一想为什么在每次登录的时候都需要用户输入密码
所有人都知道这是为了验证登录者的是否有操作权限那换一个思路想一下有没有另外一种方法也能验证登录者有这个登录权限呢
当然是有的这种验证方式建立在非对称加密协议上当客户端C想要访问服务器S时在客户端生成一对密钥(通常使用rsa协议)将客户端C生成的公钥放置在服务器S上这样在连接时只需要验证服务器S上是否存在客户端C的公钥就可以完成验证操作。(详细流程见下文) 实现SCP免密传输的操作 如果你在服务器拥有一个账号名为downey
在某一时刻你需要用一台客户机A登录到服务器上进行操作
在客户机A的家目录下的.ssh目录下生成一对秘钥linux下的指令为
ssh-keygen -t rsa -P “” (ssh-keygen为秘钥生成应用程序-t rsa 表示加密类型为rsa)
执行上述命令后系统会提示选择生成秘钥放置的目录和密码一般为默认选择一路回车。(但是如果你要追求更高的安全性你可以选择添加上私钥密码),然后在/home/downey/.ssh目录下就会生成两个文件:id_rsa和id_rsa.pub,其中id_rsa为私钥而id_rsa.pub为公钥。
在服务器端的/home/downey/.ssh/目录下新建文件authorized_keys(如果有则不用创建)将客户端A上刚刚生成的id_rsa.pub文件中的内容复制到服务器端 /home/downey/.ssh/authorized_keys文件中(如果里面有内容则另起一行)
这样就可以直接用scp指令(或者ssh登录)进行文件传输而不用进行账号密码验证了相当于客户机(操作机器)与服务器建立了安全连接(原理见下文)如果换一台机器登录依旧需要验证(因为服务器端的公钥只与这台机器上私钥相匹配)。 注意 在这些文件操作的时候特别需要注意的就是文件的权限问题很多朋友就是把文件从其他地方复制过来然后修改文件确保文件内容与目标一致就可以但是发现这样的操作并没有达到免密传输的效果很可能就是文件权限出了问题
同时在某些服务器平台上可能会提供网页端的接口来存放客户端的pub_key就像github添加公钥的操作方式但是原理都是将客户端公钥添加到服务器中 免密传输的登录流程
实现SCP传输的第一步是通信双方进行安全连接(登录)上面提到的SSH登录流程为SSH首次登录的大概讲解我们不妨来详细探究在免密传输时的登录流程
客户端向服务端发送连接请求询问服务器是否支持pubkey的方式进行登录
服务端收到客户端的请求表示接收pubkey的方式进行登录。
接收到服务端的回复客户端决定使用pubkey的方式进行登录客户端将一段数据用私钥进行加密生成签名并且将自己的公钥发送给服务器。
服务端收到客户端发过来的数据首先将客户端的公钥取出来在/home/$USER/.ssh/authorized_keys/中查找是否存在客户端的公钥如果有进行对比。 仅仅对比是否存在客户端的公钥当然是不够安全的服务器接着使用客户端提供的公钥对客户端发过来的签名(经私钥加密)进行解密如果解密后的数据内容正确表示整个验证流程完成。
服务端返回登录结果。 SSH登录流程疑难解答 客户端发送给服务器的签名数据 在上述免密传输的登录部分的第三点我有提到客户端将一段数据用私钥加密生成签名然后服务器再对这段数据进行解密那么服务器怎么知道这段数据是否正确呢
首先客户端发送给服务器的数据字段是这样的
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string publickey
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature //数据签名部分而客户端使用私钥进行加密的数据字段是这样的
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string publickey
boolean TRUE
string public key algorithm name
string public key to be used for authentication 对比发现事实上客户端同时发了一份数据和数据的签名给服务端服务端就可以做对比了。 为什么公钥可以对私钥加密的数据解密 很多朋友看完上述免密传输登录流程之后表示非常疑惑
为什么公钥可以对私钥加密的数据进行解密 公钥本来就是公开的那岂不是私钥加密的数据根本没有安全性可言 首先回答第一个问题为什么公钥可以对私钥的加密数据进行解密。答案是这是SSH协议的规定(好像是废话)。
好吧正经地回答第二个问题公钥是公开的所有人都可以获得而私钥只有拥有者才有那由这对密钥加密的数据是否就没有安全性可言呢
答案当然不是安全性高着呢。只是一般的加密过程是公钥加密私钥解密这部分数据自然是安全的。
那么私钥加密的数据呢私钥加密的数据确实没有安全性可言因为用私钥加密数据根本就不是为了安全性而是作为一种验证身份的手段。 因为私钥是唯一的一旦使用公钥对私钥加密的数据解密成功服务端S就可以完全确定这条消息是由拥有对应私钥的客户端C发出的而不是第三方伪装者发出的。
所以公钥加密私钥解密是为了数据的安全性而私钥加密公钥解密则是为了验证数据发送者的身份。 数据传输的加密方式 一般情况下SSH使用rsa加密算法登录SCP基于SSH协议所以很多人自然地认为在数据传输时使用的加密算法也是rsa。
事实上由于非对称加密算法计算太过于耗时对所有数据进行加密根本不现实所以在传输数据时一般使用对称加密算法。
上面有提到对称加密算法的弊端是密钥传输过程容易被窃取所以通常使用非对称加密算法来传输对称加密算法的密钥来保证安全性。
为此我还使用wareshark工具试图梳理整个数据传输流程花了一天的时间得出一个结论针对整个SCP实现的加密算法这一块以博主的水平暂时惹不起…(不过也只是暂时)
不过收获还是有的SCP数据传输流程结合了多种加密算法同时还根据不同级别的安全要求结合不同的加密算法。
一般来说综合对称和非对称加密算法的特性非对称加密一般用于登录验证、密钥传输等数据量小、安全性要求较高的的部分。
而对称算法用来传输大量数据。 网上的错误描述 事实上网络上对于SSH的登录过程描述有不少错误之处最经典的一个错误观点是服务器发送一个通过公钥加密的字符串给客户端客户端私钥进行解密然后发给服务端。
服务端将发出的字符串与收到的字符串进行对于完成验证过程。
这种做法看起来是非常合理的但事实上SSH并不采用这种做法具体原因引用官方文档中的一句话
the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction。 这句话意思很简单加密的计算操作是非常耗时的我们应该避免不必要的交互以节省资源。
为什么我那么自信确定它们的描述有误呢并不是飘柔给我的自信而是官方文档
(多嘴一句找资源一定要先找官方文档的) github的免密传输 用过github的盆友可能对免密传输有种熟悉的感觉没错在github的配置中如果需要进行免密传输流程是
在客户机生成一对秘钥同样是id_rsa,id_rsa.pub
将id_rsa.pub里的内容添加到github的settings的SSH and GPG keys选项页面中
同样的相当于github服务端与机器已经建立用户识别机制不需要再用账号密码来识别。 好了关于SCP传输的讨论就到此为止啦如果朋友们对于这个有什么疑问或者发现有文章中有什么错误欢迎留言
原创博客转载请注明出处
