Amazon AWS 使用心得（摸索篇一）

本文主要讲述本人使用过程中，Amazon Aws 内常用模块说明。

1 固定IP怎么配置？
答： EC2默认动态IP，每次实例重启，IP都会发生改变。这么做的好处，个人理解是鼓励大家不要使用免费实例。嘿嘿
而如果选择收费实例时，可选择绑定IP，达到固定IP效果。具体配置如下图：
11 分配d性IP

12 将d性IP关联至EC2 实例

2 负载均衡的使用？
答： 个人感觉使用AWS负载能减轻本人的运维工作，毕竟不是专业运维人员。比较明显的好处就是，不需要在服务器中安装nginx搭建负载了。
具体配置如下图：
21 创建负载均衡器，选择Application Load Balancer。

22 填写负载均衡器信息。

23 选择EC2所在区

24 选择或配置安全组，继续下一步；
25 配置路由，填写完成继续下一步，具体如下图：

26 选择应用所在EC2实例，并提交审核。

27 等待负载均衡器安装完成，即可使用。

1 访问权限问题
答： 如果是公开的S3存储桶，则忽略此项。要开启S3 API访问权限，需配置2步：
11 配置阻止公有访问(存储桶设置)，如下图：

12 配置存储桶策略，内容大概：

2 静态页面托管问题
答： S3自身除非公开存储桶，否则无法直接访问存储桶数据。如想通过存储桶来托管静态页面，目前知道的需注意以下2点：
21 存储桶名词需与域名保持一致；
22 为避免直连存储桶，可考虑使用CloudFront来实现转发达到目的。

亚马逊AWS安全凭证用于验证你以及授权任何第三方应用访问你的AWS帐号，有各种不同的AWS安全凭证可用，如密码、访问密钥、多因素身份验证、X509证书等。如果你想要创建新的访问密钥（访问密钥ID和秘密访问密钥），请按一下步骤进行。首先，登录到AWS控制台。从顶部栏选择“安全凭证”菜单（图中红色方框所示）。在下一页中，选择“访问密钥（访问密钥ID和秘密访问密钥）”选项（图中红色方框所示）。在下一页中，你将看到一个现存访问密钥ID列表（如果有的话）。注意，你不能恢复现存访问密钥ID的“秘密访问密钥”。出于安全的原因，秘密访问密钥只能在你创建新访问密钥时才可见。点击“创建新访问密钥”（见图示），将会立即创建一个新的访问密钥ID和密码访问密钥对。要么下载一个包含有新访问密钥的密钥文件，要么复制并粘贴新访问密钥信息。再次提请牢记，一旦你关闭该窗口，秘密访问密钥将不再可用，除非你下载一个密钥文件。多用户AWS帐号如果你是作为公司身份创建的帐号，多个雇员共享这一公司帐号，你可能想要使用身份和访问管理（IAM）来创建并管理他们的访问密钥。IAM是一个web服务，它允许一个公司管理多个用户及其与一个AWS帐号关联的安全凭证。使用IAM，多个用户可以作为不同身份登入单一的AWS帐号，并管理他们的安全凭证而不会相互干预对方的密钥。要管理IAM用户，点击“安全凭证”页面上的“用户”菜单（见图示）。然后，你就可以创建一个新的IAM用户并管理他们的安全凭证，比如访问密钥之类的东西。via:译者：GOLinux校对：wxy本文由LCTT原创翻译，Linux中国荣誉推出

下面的方法可以在自己的linux主机上生成securecrt需要的密钥。 首先在 AWS 管理面板中生成密钥对。 将密钥上传到一台自己的linux主机，下面举例文件名为 amazon-ec2-keypem 修改亚马逊提供的密钥文件权限： chmod og-r amazon-ec2-keypem 改写

在 《使用wireshark分析ssh口令登录细节》 和 《ssh工具，开发者必须有所了解》 这两篇文章中，我们知道了SSH登录有两种登录验证方式，其中口令登录方式使用简单，但会遇到安全问题，比如遇到中间人攻击，就会泄漏服务器的root口令。所以从安全的角度来看，建议使用另外一种登录验证方式，这就是密钥对登录方式。

密钥对验证方式对于初学者来说并不是很友好，所以我分两篇文章把这个事情说清楚，本文主要从原理的角度讲解，让你了解这种方式运作的流程，下一篇从实战的角度手把手教你登录ssh服务器。

对于开发者来说，也请务必学会使用密钥对方式登录服务器，因为现在很多应用和服务推荐这种方式，比如Github就可以使用密钥对方式连接，AWS默认就禁止口令登录。

网上有很多文章介绍ssh口令登录，但客观的说，很多文章讲错了。

很多人大概是这样理解的，客户端生成一个公开密码学算法的密钥对（注意不是ssh服务器端的密钥对），然后将公钥放到ssh服务器上的 authorized_keys 文件中（潜台词就是你有ssh权限才能 *** 作）。

然后ssh如何登录呢在连接过程中，会将客户端密钥对的公钥发送给ssh服务器，服务器在 authorized_keys 文件中匹配到这个公钥，就认为登录成功了，其实这个理解是有问题的。

核心的两个问题：

知道了这个结论后，我们看看详细的登录验证过程，在 《使用wireshark分析ssh口令登录细节》 中说过，ssh登录分为两个阶段，不管是哪一种登录验证，第一阶段的过程都是相同的，区别在于第二阶段。

有的同学说，这次你为啥不用wireshark分析了？因为第二阶段的消息传递都是加密保护的，并不能解密出具体的消息格式，这一点和TLS协议非常不同，TLS协议有多种方式可以解密出明文，而SSH协议是不支持的，所以wireshark只能显示密文。

基于这一点，本文就不用wireshark分析了，简单谈一谈ssh密钥对登录的流程，要经过多个消息交互。

第二阶段具体的流程如下：

1：ssh客户端生成一个 key ID（这个ID是基于密钥对的公钥算出来的，具体格式未知），再一次说明，这个密钥对不是服务器的，使用会话密钥加密后发送给服务器端。

2：服务器端从 authorized_keys 文件中匹配 key ID，如果匹配，此时还不能证明这个ssh客户端是真正的客户端密钥对的主人。

3：服务器端生成一个随机数，然后用客户端的公钥加密后发送给客户端。

4：客户端使用自己的私钥解密出服务器端的随机数，注意，如果某个攻击者仅仅有客户端的公钥，它是无法解密出的，因为攻击者没有对应的私钥。

5：为了向服务器端证明它能解密出这个随机数，客户端将解密出的随机数用会话密钥加密，将得到的值进行MD5运算。然后将这个值发送给服务器，以便响应（4）阶段的消息。

6：服务器端对原始随机数也使用会话密钥加密，再进行MD5计算，如果得出的值和（5）阶段客户端发送的一致，代表双方的登录校验通过。

服务器端使用服务器密钥对公钥指纹像客户端证明它就是真正的服务器端；而客户端使用它自己的密钥对向服务器证明它就是真实的客户端。

由于在验证过程中，客户端密钥对的公钥不会传输，所以即使遇到中间人攻击，攻击者也不会获取到公钥（不考虑客户端机器本身遇到攻击了）。

如果客户端的公钥曾经泄漏过，攻击者也不能成功登录ssh服务器，原因是攻击者没有私钥，无法解密出随机数，从而不能完成验证。

当然如果客户端密钥对公钥和私钥全部泄漏了，那就当我什么也没说，所以定期更换密钥对还是有好处的。

基于以上两点，我认为ssh密钥对登录是安全的，也是推荐的。

使用stunnel命令创建到 redis 节点的 SSL 隧道。然后，您可以使用 redis-cli 连接到从隧道，以便从加密的 Redis 节点访问数据。具体步骤如下所示：

在aws上找台ec2服务器， SSH登陆服务器，安装stunnel
1、sudo yum -y install stunnel

注明：

使用netstat命令确认隧道已启动

/home/ec2-user/redis-stable/src/redis-cli -h localhost -p 6379

sudo pkill stunnel

6、到此我们stunnel隧道已做好，下面就是直接在Windows上可视化工具连接。
这里有一个坑，我刚开始使用RDM连接redis，可以连接，但是无法查看数据，经过多方尝试，更换可视化客户端后正常。

7、如下图所示，连接redis服务器，命令行可用，但是db0无法显示数据。

8、多次尝试后，更换可视化工具可正常，正常使用可视化工具：Another Redis Desktop Manager。可以正常查看redis各项信息及数据。

 使用VPC wizard创建包含public subnet的 VPC后， AWS会自动产生一个default security group安全组，里面只有一条策略，就是来自本安全组的源可以访问所有的内容。

当启动EC2 instance在VPC中，并选择了这个public subnet的时候，通常都会为EC2再创建对应的security group，方便管理对应的服务器端口。

这时由于default security group中没有开放对该EC2 sg的访问，EC2 instance会无法连通AWS提供的gateway设备，导致网络不通。需要在default中增加一条策略，允许来自EC2 security group的源访问所有的内容。

如果EC2 instance用的是default的安全组，就不会有以上问题。

---