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实例从一个账号迁移到另一个账号,这里有几个问题需要注意:

  1. AMI可以分享,但只能在同一个区域内,如果跨区域只能先复制到同区域再进行分享
  2. 使用AMI镜像时需要分配大于制作镜像时磁盘大小,所以在创建实例时磁盘应该尽可能合理,否则分配了100G实际只用3G,那么用这个AMI最少也要分配100G才行
  3. 使用共享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,密钥已经无法找到,这种情况我已经遇到了两次,都是经了几手的项目,密钥早已经找不到了,我们知道这个密钥只能在创建时下载一次,丢了就几乎无法再登录这个实例了,很多时候需要删除重建了。

为什么说几乎呢?因为没有密钥也不是完全没有办法再登录进去,我在这走了很多弯路,你可以先检测一下这几个问题,对你或许有帮助

  1. 再找找原来的密钥,如果能找到这是最方便的途径
  2. 使用AWS网站后台的“连接”按钮,来直连实例
  3. 检查实例的安全规则,看看22端口是否放行,是否使用其他端口来运行ssh服务了

查询端口是否连通的办法有 telnet ip portnmap -p port ip 等多种办法

前两种方法我都试了行不通,而第三种遇到问题时还没意识到,所以我使用了“必杀技”,将无法连接的实例硬盘分离,然后挂载到其他可以登录的实例,然后挂载修改ssh密钥,再挂载回去重新登录即可,挂载到其他实例的命令如下,根据实际情况调整

1
2
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 选项,输出以下关键调试信息

1
2
3
4
5
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的端口
  • 如果密钥真的丢了就把实例的硬盘挂载到其他的实例上修改密钥吧

==>> 反爬链接,请勿点击,原地爆炸,概不负责!<<==

你我皆凡人,生在人世间。终日奔波苦,一刻不得闲。既然不是仙,难免有杂念。道义放两旁,利字摆中间~

无德无行而取厚利,必有奇祸;善行善德而受磨难,必有后福;修德以配位,自谦以远祸。以色相交者,色衰而爱弛;以利相交者,利尽而交疏;以势相交者,势倾而交绝;以道相交者,天荒而地老;以德相交者,地久而天长;你用什么吸引人,你吸引的就是什么样的人。

2024-9-22 00:10:51

Albert Shi wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客