AWS镜像迁移登录问题二三则
文章目录
- 前言
- EC2镜像迁移
- 无法登录古老的AWS实例
- 总结
前言
关于云服务器之前用的多的还是国内的阿里云和腾讯云，也用过一点点的华为云，而今年接触的AWS和GCP比较多，使用场景渐渐多了起来，遇到的问题也渐渐多了起来，之前这些都是有专门的运维同事负责的，而现在降本增效之后只能自己上了，这两条在捣鼓AWS，就先记录一些AWS上遇到的问题和解决办法吧，关于问题我尽量贴一些原始的报错，便于有相同问题的人进行对照。
EC2镜像迁移
此文章的本意是记录遇到的问题和解决办法，所以我在这不会详细描述怎样做镜像，自己去搜索文档吧，要实在找不到可以留言等有空我帮你找下，说说镜像有什么用，在AWS中的系统镜像被称为AMI，全称Amazon Machine Image，可以简单的连接为操作系统，不过要更好用一些。
现实中我们买一台新电脑是先挑硬件组装好，然后安装操作系统，Windows、Linux都可以，如果是云服务器比如AWS，也是先选配置比如CPU、内存、硬盘等等，然后选择一个AMI就可以安装使用了，如果你操作很熟练的话，大概几秒钟就可以得到一台可以立即使用的特定配置的云服务器。
这里的镜像可以选择官方Windows、Linux、Mac等官方支持的系统，也可以选择第三方的，甚至是自己可以定制的，比如你的项目大量使用Ubuntu+XXX的机器，每次创建Ubuntu实例后都要安装XXX软件，这就很麻烦，你可以使用安装好XXX的实例创建映像，保存下来，以后创建新的实例时直接使用这个AMI就很方便了，有点像Docker，但这比Docker要重度一些。
而我使用这个映像的情景是项目的迁移，将AWS实例从一个账号迁移到另一个账号，这里有几个问题需要注意：
- AMI可以分享，但只能在同一个区域内，如果跨区域只能先复制到同区域再进行分享
- 使用AMI镜像时需要分配大于制作镜像时磁盘大小，所以在创建实例时磁盘应该尽可能合理，否则分配了100G实际只用3G，那么用这个AMI最少也要分配100G才行
- 使用共享AMI先要浏览获取基础映像的授权，我在这遇到了一个问题，选择了另一个账号的AMI，但是启动失败，提示错误如下：
In order to use this AWS Marketplace product you need to accept terms and subscribe. To do so please visit https://aws.amazon.com/marketplace/pp?sku=aw0evgkw8e5c1q413zgy5pjce
其实你访问提供的链接会看到产品的详细信息和定价。你需要阅读并接受产品条款，然后点击“Continue”或类似的按钮完成订阅。之后你就可以返回 AWS 管理控制台，再次尝试启动实例，这时候应该可以成功启动。
无法登录古老的AWS实例
无法登录的原因，并不一定是因为AWS出问题了，AWS本身出问题不能说完全没有，但是这种情况概率比较小，来聊聊我遇到的情况。
接手别的项目组的AWS，密钥已经无法找到，这种情况我已经遇到了两次，都是经了几手的项目，密钥早已经找不到了，我们知道这个密钥只能在创建时下载一次，丢了就几乎无法再登录这个实例了，很多时候需要删除重建了。
为什么说几乎呢？因为没有密钥也不是完全没有办法再登录进去，我在这走了很多弯路，你可以先检测一下这几个问题，对你或许有帮助
- 再找找原来的密钥，如果能找到这是最方便的途径
- 使用AWS网站后台的“连接”按钮，来直连实例
- 检查实例的安全规则，看看22端口是否放行，是否使用其他端口来运行ssh服务了
查询端口是否连通的办法有 telnet ip port 或 nmap -p port ip 等多种办法
前两种方法我都试了行不通，而第三种遇到问题时还没意识到，所以我使用了“必杀技”，将无法连接的实例硬盘分离，然后挂载到其他可以登录的实例，然后挂载修改ssh密钥，再挂载回去重新登录即可，挂载到其他实例的命令如下，根据实际情况调整
mkdir /mnt/temp
sudo mount /dev/xvdb1 /mnt/temp
这时你可能会遇到报错，提示你挂载报错，大概率是UUID重复了，可以修改挂载命令 sudo mount -o nouuid /dev/xvdb1 /mnt/temp
但我修改后还是不能登录，后来发现端口22不通，我一度以为这个实例没有启动ssh服务，尝试了多种方法，走了很多弯路，比如 chroot 或者修改用户数据添加启动ssh命令的脚本但都没有效果，最终发现是ssh服务器被改到了2022端口，废了九牛二虎之力终于可以访问ssh服务了，但还是认证失败
ssh登录时添加 -vvv 选项，输出以下关键调试信息
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
关键是 receive packet: type 51 这一句表示publickey验证失败，如果能登录这里应该是 receive packet: type 52，原因大概率就是publickey出了问题，我是因为没把publickey放到服务器上，不过我也很奇怪，创建实例时明明选了密钥，可能因为一开始启动报错就没放上去，导致了后面一系列弯路
总结
- AWS 和 GCP 是全球主流的云服务，Microsoft 的 Azure至今还没用过
- 如果想重用一个云服务环境，可以将这个实例创建成一个AMI保存
- 如果无法登录实例看看安全规则有没有换ssh的端口
- 如果密钥真的丢了就把实例的硬盘挂载到其他的实例上修改密钥吧
你我皆凡人，生在人世间。终日奔波苦，一刻不得闲。既然不是仙，难免有杂念。道义放两旁，利字摆中间~
无德无行而取厚利，必有奇祸；善行善德而受磨难，必有后福；修德以配位，自谦以远祸。以色相交者，色衰而爱弛；以利相交者，利尽而交疏；以势相交者，势倾而交绝；以道相交者，天荒而地老；以德相交者，地久而天长；你用什么吸引人，你吸引的就是什么样的人。