OpenSSL

openstack学习-计算管理

时间秒杀一切 提交于 2020-08-17 06:29:57
实验通过openstack dashboard和openstack CLI两种方式管理Hypervisor、主机聚合、规格密钥对以及虚拟机组的测试,并测试虚拟机发放、生命周期管理以及快照和重建等 Openstack Dashboard操作 Hypervisor和主机聚合管理 主机聚合通过将主机组合到一起来把可用区域划分成逻辑单元。创建一个主机聚合,然后选择要放里面的主机。 使用admin用户登陆Openstack Dashboard界面。在导航栏选择“管理员-计算-虚拟机管理器”,进入虚拟机列表,查看hypervsior概览等信息。 选择“计算主机”,计入计算主机列表,查看计算节点信息 导航栏,选择“管理员-计算-主机聚合”,进入主机聚合列表,点击创建主机聚合 在“主机聚合”中,输入主机聚合名称“HostAggr_web和可用分区名称"nova" 选择”管理聚合内的主机“,将可用主机compute1添加进来,完成主机聚合的创建 返回主机聚合列表,显示刚刚创建的主机聚合 可见,主机聚合已经成功创建 删除主机聚合里面的主机,在”管理聚合内的主机“中,点击删除即可 规格管理 在”管理员-计算-规格(实例类型)“中,进入规格列表,点击创建规格 在”创建实例类型信息“中,按照如下方式进行填写 名称:Flavor_web_test vcpus:1 RAM(MB):128 Root Disk

centos7 升级openssh到openssh-8.0p1版本

随声附和 提交于 2020-08-17 06:25:19
环境介绍 centos7.3和centos7.6升级完毕测试登录ssh以及重启后登录ssh均无问题。 前期请自行配置好yum源(如果不会请百度) 整个过程不需要卸载原先的openssl包和openssh的rpm包。不影响我们的操作 本文的环境都是系统自带的openssh,没有经历过手动编译安装方式。如果之前有手动编译安装过openssh,请参照本文自行测试是否能成功。 如果严格参照本文操作,我保证你升级没问题 centos7.6升级后的效果 [root@testssh ~]# ssh -V OpenSSH_8.0p1, OpenSSL 1.0.2r 26 Feb 2019 [root@testssh ~]# openssl version OpenSSL 1.0.2r 26 Feb 2019 [root@testssh ~]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) [root@testssh ~]#    centos7.3升级后的效果 [root@linux-node3 ~]# openssl version OpenSSL 1.0.2r 26 Feb 2019 [root@linux-node3 ~]# ssh -V OpenSSH_8.0p1, OpenSSL 1.0.2r 26 Feb

单向认证和双向认证

扶醉桌前 提交于 2020-08-17 06:21:00
SSL协议即用到了对称加密也用到了非对称加密(公钥加密),在建立传输链路时,SSL首先对对称加密的密钥使用公钥进行非对称加密,链路建立好之后,SSL对传输内容使用对称加密。 一、单向认证 Https在建立Socket连接之前,需要进行握手,具体过程如下: 1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。 2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息,同时也返回服务器端的证书,即公钥证书 3、客户端使用服务端返回的信息验证服务器的合法性,包括: 证书是否过期 发型服务器证书的CA是否可靠 返回的公钥是否能正确解开返回证书中的数字签名 服务器证书上的域名是否和服务器的实际域名相匹配 验证通过后,将继续进行通信,否则,终止通信 4、客户端向服务端发送自己所能支持的对称加密方案,供服务器端进行选择 5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。 6、服务器将选择好的加密方案通过明文方式返回给客户端 7、客户端接收到服务端返回的加密方式后,使用该加密方式生成产生随机码,用作通信过程中对称加密的密钥,使用服务端返回的公钥进行加密,将加密后的随机码发送至服务器 8、服务器收到客户端返回的加密信息后,使用自己的私钥进行解密,获取对称加密密钥。 在接下来的会话中,服务器和客户端将会使用该密码进行对称加密,保证通信过程中信息的安全。 二

使用gpg插件发布jar包到Maven中央仓库 完整实践

ⅰ亾dé卋堺 提交于 2020-08-17 05:30:38
本文记录了在maven环境下使用gpg插件将 jar 包部署到中央仓库并快速检验和更新的完整实践过程。相对于网上其他教程使用oss-parent作为父工程的方法,这种方法入侵度低,自由度高,也是官方推荐使用的。实践过程解决了gpg验证以及javadoc注解不规范的问题。 先行知识 1 项目基础配置 首先需要注意项目的 groupId,下文注册sonatype账号时也需要填写 groupId ,两者最好一致,并确保你拥有该域名所有权,我推荐用GitHub个人主页作为对应地址。格式为 com.github.username。首先需要注意项目的 groupId,下文注册sonatype账号时也需要填写 groupId ,两者最好一致,并确保你拥有该域名所有权,我推荐用GitHub个人主页作为对应地址。格式为 com.github.username。 本文以如下配置为例: <groupId>com.github.linshenkx</groupId> <artifactId>rpc-netty-spring-boot-starter</artifactId> <version>1.0.0.RELEASE</version> 2 Maven发布相关网址 在整个发布过程中,有以下3个关键网址,注意前2个共用一个账号。 工单管理: https://issues.sonatype.org

在你的树莓派家庭实验室中使用 Cloud-init

北城余情 提交于 2020-08-17 04:54:10
了解了云行业的标准,该向你的家庭实验室自动添加新设备和用户了。 Cloud-init (可以说)是一个标准,云提供商用它来为云实例提供初始化和配置数据。它最常用于新实例的首次启动,以自动完成网络设置、账户创建和 SSH 密钥安装等使新系统上线所需的任何事情,以便用户可以访问它。 在之前的一篇文章《 修改磁盘镜像来创建基于树莓派的家庭实验室 》中,我展示了如何为像树莓派这样的单板计算机定制操作系统镜像以实现类似的目标。有了 Cloud-init,就不需要向镜像中添加自定义数据。一旦在镜像中启用了它,你的虚拟机、物理服务器,甚至是小小的树莓派都可以表现得像你自己的 “家庭私有云” 中的云计算实例。新机器只需插入、打开,就可以自动成为你的 家庭实验室 的一部分。 说实话,Cloud-init 的设计并没有考虑到家庭实验室。正如我所提到的,你可以很容易地修改给定的一套系统磁盘镜像,以启用 SSH 访问并在第一次启动后对它们进行配置。Cloud-init 是为大规模的云提供商设计的,这些提供商需要容纳许多客户,维护一组小的镜像,并为这些客户提供访问实例的机制,而无需为每个客户定制一个镜像。拥有单个管理员的家庭实验室则不会面临同样的挑战。 不过,Cloud-init 在家庭实验室中也不是没有可取之处。教育是我的家庭私有云项目的目标之一,而为你的家庭实验室设置 Cloud-init

Nginx服务器的使用与反向代理负载均衡

大憨熊 提交于 2020-08-17 04:31:39
Nginx服务器 一:什么是Nginx? 我们生活的世界中,有的时候需要上网。我们可以浏览很多很多的网页,这些网页都是由一系列的程序组成,但是我们是否想过,这些程序存储在什么地方呢?没错,这些程序都是存储在一种名叫服务器的硬件上,比如我们的电脑也是一种服务器,只不过我们的个人电脑作为服务器的话性能会比较低。我们的网页程序存储在服务器硬件上,是否可以随意存储呢?不是的,我们需要在服务器硬件的操作系统中搭建一个服务器软件,那么这样,有服务器软件跟服务器硬件配合,才形成一个完整的服务器。服务器软件有非常多,比如Apache、tomcat等等都是服务器软件,而我们今天要学习的Nginx也是一种服务器软件之一。 Nginx是一种服务器软件,故而其最主要、最基本的功能当然是可以与服务器硬件结合,让程序员可以将程序放在Nginx服务器上,将程序发布出去,让成千上万的网民可以浏览。除此之外,Nginx是一种高性能的HTTP和反向代理服务器,同时也是一个代理邮件服务器。也就是说,我们Nginx上可以发布网站,也可以实现负载均衡的功能,还可以作为邮件服务器实现收发邮件等功能。所谓的负载均衡是指,当同时有N多用户访问我们服务器的时候,为了减少服务器压力,我们需要将用户分别引入各服务器,分担服务器的压力。 Nginx与其他服努器的性能比较 首先说IIS, IIS服务器只能在Windows上运行

jenkins添加git源失败

感情迁移 提交于 2020-08-17 04:10:29
Failed to connect to repository : Command "git ls-remote -h git@192.168.91.11:test/dzp.git HEAD" returned status code 128: stdout: stderr: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 1.卸载自带的git,因为版本太低 本地服务器版本: [root@vm_001034_op-test git-2.0.5]# cat /etc/redhat-release CentOS release 6.5 (Final) [root@vm_001034_op-test git-2.0.5]# 笔者从网上找了很多资料,最终参考几份资料才安装成功的。 原因很简单

第十一节:Ocelot集成IDS4认证授权-微服务主体架构完成

一曲冷凌霜 提交于 2020-08-17 03:42:44
一. 前言 1.业务背景   我们前面尝试了在业务服务器上加IDS4校验,实际上是不合理的, 在生产环境中,业务服务器会有很多个,如果把校验加在每个业务服务器上,代码冗余且不易维护(很多情况下业务服务器不直接对外开放), 所以我们通常把校验加在Ocelot网关上,也就是说校验通过了,Ocelot网关才会把请求转发给相应的业务服务器上.(我们这里通常是网关和业务服务器在一个内网中,业务服务器不开放外网) (和前面:Jwt配合中间件校验流程上是一样的,只不过这里的认证和授权都基于IDS4来做) PS:关于IDS4服务器,可以配置在网关后面,通过网关转发;    也可以不经网关转发,单独存在, 这里要说明的是,如果经过网关转发,那么对于IDS4而言,只是单纯的转发,不走Ocelot上的校验,其实也很简单,就是 不配置AuthenticationProviderKey即可. 2.用到的项目 (1).Case2下的GateWay_Server :网关服务器 (2).Case2下的ID4_Server:认证+授权服务器 (3).GoodsService + OrderService:二者都是资源服务器 (4).PostMan:充当客户端(即第三方应用) (5).MyClient2:用控制台充当客户端(即第三方应用) (6).Consul:网关Ocelot已经集成Consul服务发现了

centos 7安装rabbitmq

狂风中的少年 提交于 2020-08-17 03:26:54
rabbitmq依赖erlang所以先安装erlang rabbitmq对erlang的版本有要求,先去官网看一下对应版本要求: https://www.rabbitmq.com/which-erlang.html 一、安装erlang 1.下载erlang安装包,去erlang官网下载 2.安装 1)安装依赖模块:yum -y install make gcc gcc-c++ kernel-devel m4 ncurses-devel openssl-devel 2)将安装包解压 ./configure --prefix=/opt/erlang --with-ssl --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe报错的话执行 sudo yum install unixODBC-devel openssl-devel ncurses-devel 3)编译 make && make install 4)配置环境变量 vim /etc/profile 加一行 export PATH=$PATH: 路径/bin 保存编译source /etc/profile 5)erl 测试是否安装成功。如图 二、安装rabbitmq 1.官网下载安装包: https://github.com

api接口安全性问题

孤者浪人 提交于 2020-08-17 02:45:45
首先是正常的接口安全性设计 1、参数签名,防止篡改(MD5,SHA1,hmacSHA1) 2、防止重放校验(一次性的验证码,接口幂等性) 3、接口加密(RSA,AES等加解密算法),可以采用rsa加密签名,aes加密数据来提高性能 到这里,如果没有账号体系,对于前后分离的web端和android端,相当于接口都是可以模拟成功的,密钥没办法安全保存 网上很多的方式是通过接口获取动态生成的密钥,那么获取密钥的接口安全如何保证,当然这样一般不考虑密钥保存问题,请求允许模拟,这样是足够的 安全性保障: 4、用户token验证机制(前提是有账号体系) 这才是保证请求安全的重要依据,登录接口获取临时token,需要防止爆发破解账号密码(手机验证码或图片验证码),后续请求都必须带上token,服务器端校验token有效性 如果别人模拟登录接口接口,但是没有账号密码,是没有办法得到token的,对于有账号密码的情况,我们可以认为这就是一个正常用户,进行正常的访问域验证,防止访问其他用户信息就可以了 这样就算是密钥丢失,也只能调用那些不需要登录的接口,而这些接口一般也没有太大的安全性要求,能做的只是限流 来源: oschina 链接: https://my.oschina.net/u/1428688/blog/4295089