태그 보관물: aws

Lightsail Ubuntu 20.04 업그레이드 후 ssh 접속 불가 현상

Lightsail의 이미지를 Ubuntu 20.04 LTS로 업그레이드 한 후 web 환경에서 SSH 접속이 되지 않아서 또 망했다며 머리를 쥐어 뜯고 있는데, 우연히, 당연히 안 될 거라고 생각했던 터미널 프로그램을 통한 SSH 접속은 또 되는 기현상을 발견했다. 이 대로도 나쁘진 않지만 좀 찜찜 하기도 하고 해서 좀 더 찾아 보았다.

접속 오류가 발생할 때의 로그를 보면 다음과 같은데,

$ cat /var/log/auth.log|tail
...
sshd[4528]: userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]
...

이 문제의 해결책에 대해 아주 자세히 설명된 Use RSA CA Certificates with OpenSSH 8.2에 따르면, (Ubuntu 20.04에 포함된) OpenSSH 8.2 부터는 보안 문제로 SHA-1 기반인 ssh-rsa가 기본 CA signature 항목에서 빠지면서 이러한 문제가 발생하게 된다고 한다. 해결 방법은 CASignatureAlgorithms에 ssh-rsa를 지원하도록 명시하는 것이다.

$ cat /etc/ssh/sshd_config|tail
...
# Use RSA CA cert.
# https://ibug.io/blog/2020/04/ssh-8.2-rsa-ca/
CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

위의 링크에서 제안하는 대로 sshd_config 파일에 CASignatureAlgorithms 항목을 위와 같이 추가 하고 sshd service를 재 실행 하고나니, web 환경 SSH가 잘 동작하게 되었다. 물론, 터미널도 그대로 잘 된다.

Lightshail Ubuntu 배포판 업그레이드 후 ssh 접속이 안된다.

망했다! Litghtsail의 Ubuntu 배포판이 너무 오래전 것이라 콘솔에 접근해서 조심스럽게 screen session도 새로 만들어 가면서 업그레이드를 했는데 끝나고 나니 SSH가 안된다. 아마도 중간에 SSH관련 환경설정을 파일을 변경할 것인지 묻는 선택메뉴가 나왔는데, 현재 설정을 그냥 쓰겠다고 했던게 문제인것 같다. 다행히 blogging service는 잘돌아 가고 있지만 SSH가 안되면 서버관리를 할 방법이 없는데…

Workaound

다행히 세상은 생각보다 넓고 인간은 같은 실수를 반복하기에 이전에 같은 실수를 한 사람의 비슷한 경험을 정보의 바다에서 찾을 수 있었다 (SSH stops working after upgrade to Ubuntu 18.04 on AWS Lightsail). 대충 Ubuntu 18.04 LTS로 올라가면서 SSH 환경설정 파일에 변경이 있었는데 메인테이너 버전을 적용하지 않으면 문제가 되는가 보다. 이 포스팅은 위의 링크에 있는 내용을 기준으로 정리한 것이다. (Lightsail 한정이고 EC2를 사용하고 있다면 아래와 같이 번거로운 작업을 할 필요가 없다고 한다)

순서 요약

  1. SSH접속이 안되는 instance로 부터 스냅샷을 하나 만든다.
  2. 스냅샷의 시작 스크립트에 ssh 환경설정을 수정하는 명령어를 넣고 새로운 인스턴스를 만든다.
  3. 잘 되면 새로운 인스턴스를 고정 IP에 연결하고 이전 인스턴스를 지운다.

스냅샷 생성

SSH 접속이 안되는 인스턴스로 부터 스냅샷을 하나 만든다. 관리 -> 스냅샷 수동 스냅샷 아래의 ‘+ 스냅샷 생성’을 클릭.

생성이 완료될 때까지 조금 기다렸다가 이 스냅샷으로 부터 새로운 인스턴스를 하나 만든다.

시작 스크립트를 추가하고 인스턴스를 실행

새 인스턴스 생성 메뉴에 보면 “시작 스크립트”를 넣는 곳이 있는데 이곳을 선택하고 ssh config를 변경해 줄 다음의 sed 명령어를 입력한다.

sudo sed -i 's/^Ciphers .*/Ciphers +aes256-cbc,aes192-cbc,aes128-cbc/' /etc/ssh/sshd_config
sudo service sshd stop
sudo service sshd start

그리고 나서 인스턴스를 실행하면 처음에는 여전히 SSH 접속이 되지 않는데, 꽤 오랜 시간 (10~20분)이 지나고 나서야 가능해 진다.

고정 IP 변경과 정리

네트워킹 -> Static IP에서 고정 IP를 분리하고 새로운 인스턴스에 새로 연결해 준다.

새로운 인스턴스를 고정 IP에 할당 한 후 기존 서버를 끄고 도메인에 접속해서 잘 돌아가는 지 확인한 후 스냅샷과 기존 인스턴스를 지워준다. 스냅샷 생성 기능은 예전에 한 번 백업용으로 좋겠다 싶어서 만들어 봤다가 추가 요금이 나온적이 있다. 🙁

결론

다음 부터는 이미지를 업데이트 하고 싶을 땐 먼저 백업을 만들어서 작업 및 확인하고 최종으로 IP를 변경 하도록 하자.

AWS Lightsail에 둥지 틀기

여러 국내 호스팅 업체들을 거쳐서 여러 곳에서 WordPress 호스팅 서비스로 추천되는 Siteground에 한동안 정착하는 듯 했다. 준수한 속도에 비해 합리적인 가격($3.95/월) 때문에 당분간 정착할 거라고 생각하고 있었는데 일년이 지나서 서비스 갱신기간이 되자 가격이 세배 넘게 올라서 1년에 $143을 달라고 한다.($11.95/월).
“이건 너무 한 거 아니냐고!”

WordPress hosting은 더 비싸다

대안으로 생각한 것은 1) wordpress.com hosting과 2) AWS Lightsail이었는데, 발견한 한 가지 놀.라.운. 사실은 WordPress hosting에서 플러그인을 설차하려면 한달에 $25 짜리 business plan 이상을 계약해야 한다는 것이다. 한달에 $25라니!!! 멋 모르고 카드 결재를 하고 이리저리 플러그인 설치를 시도하다가 아래의 표를 발견하고는 미련 없이 ‘refund’ 버튼을 눌렀다.

AWS Lightsail은 한 달간 무료 시험기간을 주기 때문에 Siteground 계정이 종료하기 전에 미리 설치를 마쳤다. 인스턴스 리전을 한국으로 할까 하다가 이전 Siteground와 같은 위치인 싱가포르로 선택했고 WordPress의 export/import 기능 덕에 마이그레이션은 수월하게 진행되었다. Domain name은 호스팅 업체와 같은 곳으로 이전하는게 좋다고 해서 AWS Route 53으로 이전 및 1년 연기 등록을 했는데 상위 도메인에 따라 다르지만 .com의 경우 $13.2(세금포함)가 소요된다. 어라? 그러고 보니 Siteground에서 도메인을 연장하는 서비스는 $15.95였는데? 이눔 시키들…

도메인 이전과 새로운 IP 연결

도메인 이전을 요청하니 이전 관리자였던 Siteground에서 확인 메일이 왔고, 수락한 이후에는 하루 후에 AWS로 도메인이 이전되었다. 그 후에는 Lightsail의 네트워킹 탭에서 고정 IP와 DNS 영역을 생성해서 A 레코드를 추가하고 IP와 도메인 이름을 연결 시켜 주었다.

그리고 나서 한참을 DNS가 업데이트 되기를 기다렸다. nslookup은 여전히 예전 IP를 보여줬지만 48시간 까지 걸릴 수 있다는 말에 이틀정도를 기다렸는데도 IP가 업데이트 되지 않았다. AWS Route 53에 가보니 ‘registered domains > [domain name]’ 아래에 Name Servers 항목이 있는데 혹시 이것 때문인가 싶어서 고정 IP를 만들때 나왔던 네임서버 목록으로 업데이트를 해주었다. 그리고 나서 잠시 후 드디어 새로운 IP로 접속되었다!

계속 예전 IP로 돌아가는 도메인 문제와 해결

기쁜 마음으로 꿀잠에 들었는데 다음날 아침에 보니 Jetpack에서 서버연결 붙었다가 끊어졌다가 했다는 연락이 와 있었다. 혹시나 싶어서 서버를 재부팅 해봤더니 재부팅하는 순간 잠깐 IP가 새 것으로 붙었다가 다시 예전 IP로 돌아가는게 보였다. 그니까 누가 AWS 알고 있는 것과 다른 예전 정보를 자꾸 준다는 거지…” 혹시나 하는 마음에 Siteground의 cPannel > Advanced DNS zone editor에 들어가 봤더니 역시나 얘가 예전 주소를 꼭 쥐고 있었다. 예전 사업자의 도메인 서버를 AWS 고정 IP로 수정해 주고 났더니 Jetpack이 사이트 살아났다고 축하한댄다. 다행히 그 후로는 다시 끊어지는 일은 없었다.

도메인 관리자를 변경하고 새로운 IP를 연결 했으니 이전 네임 서버에서는 자동으로 놔 주겠거니 하고 잘 못 생각하고 있었던게 문제 였던듯 싶다.

WordPress permalink(고유주소) 변경

WordPress의 permalink(고유주소) 형식을 변경하면 검색 엔진을 포함해서 외부에서 들어 오는 링크가 동작하지 않는다. 서버에 대한 root권한이 없다면 .htaccess file에, 권한이 있다면 apache2.conf에 새로운 형식의 permalink로 연결되도록 설정해 주는 것으로 이 문제를 해결 할 수 있다.

처음에는 서버를 재시작 할 필요가 없는 .htaccess에 관련 설정을 했었는데,  아파치 튜토리얼: .htaccess 파일 문서에 .htaccess file 설정은 성능에 영향을 미칠 수 있으므로 권한이 있는 경우라면 apache2.conf에 설정하라는 이야기가 있어서 이것을 수정했다.

먼저 Apache2의 rewrite module을 enable한다.

$ sudo a2enmod rewrite

그다음 apache2.conf에 관련 설정을 추가한다.

#
# Rewrite settings.
#
# Articles
#    e.g) ~/archives/1234 -> ~/?p=1234
# Tags/Categories
#    e.g) ~/archives/tag/database -> ~/?tag=database
# Dates
#    e.g) ~/archives/date/2013/02 -> ~/?m=201302
<IfModule mod_rewrite.c>
    RewriteEngine On
    RedirectMatch 301 ^/archives/(\d+)$ http://54.179.110.104/?p=$1
    RedirectMatch 301 ^/archives/(\w+)/(\w+)$ http://54.179.110.104/?$1=$2
    RedirectMatch 301 ^/archives/date/([0-9]{4})/([0-9]{2})$ http://54.179.110.104/?m=$1$2
</IfModule>


이 설정은 이전의 /archives/xxxx 형식의 글이나, /archives/tag/xxxx 형식의 tag, /archives/yyyy/mm 형식의 날짜를 “Ugly”한 기본 형식으로 변경하기 위한 것이다.

마지막으로 Apache2 서버를 재시작해준다.

$ sudo service apache2 restart