kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

GitHubのRSA SSH ホスト鍵変更に対してクライアント側の修正方法

GitHubのRSA SSH 秘密鍵が漏洩したため、2023/03/24 にGitHubのRSA SSH ホスト鍵が変更されました

github.blog

RSA SSH 秘密鍵って?

  • RSAは暗号化方式
  • RSA SSH 秘密鍵は、RSAでSSHするためにGitHubが持っている秘密鍵
  • 今回これが漏洩した

RSA SSH ホスト鍵って?

  • 秘密鍵と公開鍵のペアのこと
  • クライアント側は、接続するサーバから公開鍵を受け取って known_hosts に格納する
  • known_hosts に鍵が格納されると、次回以降のSSH接続では、known_hosts にある公開鍵と、サーバから受け取る公開鍵に差異が無いことを確認して、サーバが偽物に成り代わっていないかチェックするようになる

ホスト鍵が変わると何が困るの?

ホスト鍵(公開鍵も)が変わり、known_hosts にある GitHub の公開鍵と、GitHub受け取る公開鍵に差異が発生するため、SSH接続が失敗するようになる

具体的にはこんなエラーが出る

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d5:2c:63:d9:bc:75:9d:de:b1:4e:36:28:9f:7a:9c:39.
Please contact your system administrator.
Add correct host key in /home/hoge/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/hoge/.ssh/known_hosts:3
RSA host key for github.com has changed and you have requested strict checking.
Host key verification failed.

👆/home/hoge/.ssh/known_hosts の3行目にある公開鍵と、サーバから受け取った公開鍵が違うよというエラーメッセージ

どうしたら良いの?

公式ドキュメントの手順に従えばOK

known_hosts から古い公開鍵を削除

ssh-keygen -f /home/hoge/.ssh/known_hosts -R github.com

👆github.com に関する known_hosts の情報を削除するよというコマンド

known_hosts に手動で以下の公開鍵を追加

github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=

実際に GitHub に SSH して動作確認する

$ ssh -T git@github.com

Warning: Permanently added the RSA host key for IP address '20.27.177.113' to the list of known hosts.
Hi hoge! You've successfully authenticated, but GitHub does not provide shell access.

警告が出なければOK

ウチのサーバの場合、さらに以下の警告も出たので同様に公開鍵を削除した

Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '20.27.177.113'
ssh-keygen -R 20.27.177.113

参考

SSH公開鍵については、過去のblog記事で解説してます

kasei-san.hatenadiary.org

AWS コスト削減チェックリスト

前提

  • 金銭的なコスト削減のために、運用コストが上昇したら元も子もないので注意!!!

全体

  • EC2 から、ECS(Fargate)、lambdaへの移行を検討中ならば、Compute Savings Plansを使用する
  • そもそも使っていないインスタンスを停止する

EC2

  • 性能が過剰ならば、より低スペックのインスタンスに変更する
  • インスタンスタイプが古いのであれば、最新にする(最新のほうが安い
  • 可能であれば、CPUを Graviton に変更する
  • 24H稼働が不要であれば、夜間休日は停止する(検証環境や営業時間しか使わないサービスなど)
  • 停止しても問題なければ、スポットインスタンスに変更する
  • 1年以上使用するのであれば、リザーブドインスタンスやSavings Plansを契約する
  • バッチ処理などは、ECS(fargate)やlambdaへの移行を検討する
    • → そもそもEC2は運用コストが高い場合が多い
  • オートスケーリンググループを使って、低負荷時はマシンを停止する

ECS(fargate)

  • 性能が過剰ならば、メモリやCPUを減らす
  • 可能であれば、CPUを Graviton に変更する
  • 24H稼働が不要であれば、夜間休日は停止する(検証環境や営業時間しか使わないサービスなど)
  • 停止しても問題なければ、Fargate Spotに変更する
  • 稼働する量が決まっているならば、Savings Plansを契約する
  • 処理頻度が低いのであれば、lambdaに移行する

RDS(Aurora)

  • 性能が過剰ならば、インスタンスタイプを下げる
  • CPUを Graviton に変更する
  • 低頻度アクセスや社内利用であれば、Aurora Serverlessへ移行する
  • 1年以上使用するのであれば、リザーブドインスタンスやSavings Plansを契約する
  • 不要ならばバックアップ保持期間を短くする
  • IOが多いならば、Aurora I/O 最適化を検討する

lambda

  • メモリ使用量が過剰ならば減らす → Lambda Power Tuning
  • 可能であれば、CPUを Graviton に変更する
  • 実行可否をlambda内で処理しているのならば、イベントフィルタリングを使ってlambdaを実行させないようにする
  • 実行頻度が高いのであれば、ECS(fargate)に移行したほうが安いかも

S3

  • 不要なのに保存しているオブジェクトを廃棄する
    • もしくは、数ヶ月経過後はアーカイブする
  • 消えても大きく問題がないオブジェクトは、シングルAZに変更する
  • アクセス頻度が低いオブジェクトは、低頻度アクセスやアーカイブに変更する
  • S3Intelligent-Tieringを使って自動的にコスト最適化を行う

PostgreSQLでのdump、restore、COPYおぼえがき

データベースの dump

pg_dump -d ${dbname}  > /var/tmp/dbname.dump

特定のテーブルのみ dump

pg_dump -d ${dbname} -t ${tablename}  > /var/tmp/dbname.dump

特定のテーブル 以外を dump

pg_dump -d ${dbname} -T ${tablename}  > /var/tmp/dbname.dump

データベースのリストア

pg_restore -d ${dbname} --jobs8  /var/tmp/dbname.dump
  • jobs オプションは、indexの作成などを複数ジョブで実行するためのコマンド。CPUの数以内にする

上記の場合、dumpファイルにDBの削除/生成の命令は入らないので、リストア前に手動でDBを削除/生成する必要がある

COPYコマンドを使って、データの一部だけdump,restoreする方法

データのdump

COPY  (SELECT * FROM ${table_name} WHERE id > 123456789) TO '/var/tmp/tablename.dump';

データのrestore

COPY  (SELECT * FROM ${table_name} WHERE id > 123456789) FROM '/var/tmp/tablename.dump';
  • テーブルは生成されないので、先に以下のコマンドでdump/restoreしておく

テーブルのスキーマのみdumpする方法

pg_dump -d idoudb --no-acl -t ${table_name} -s > /var/tmp/table_name_schema.sql

Aurora PostgreSQLにCOPYコマンドでrestoreする方法

Auroraにはファイルを置けないので、標準入力を使う

cat /var/tmp/tablename.dump | psql -c "COPY tablename FROM STDIN"

参考

最近のかせいさんの情報収集方法 2021年版

この記事はLCL Advent Calendar 2021 - 18日目です。

qiita.com

こんにちは、 id:kasei_san です。

皆さん、技術情報の情報収集どうしてますか?

昔はLiveDoorReaderとか、はてなブックマークとかで集めれば割と良かったのですが、RSSがオワコンになり、はてなブックマークも(個人的には)ノイズが多くて使いづらくなってしまい、どうしたものかと考えています。

今回は、かせいさんの試行錯誤中の情報収集方法を晒して「みんなどうしてる?」という意見を伺いたくて、記事を書いてみました。

なので、「自分はこうしてるよ!」とか「こうしたらどう?」とかあったら、コメントなりはてブなり、引用RTなりで何かフィードバックいただけると嬉しいです。

それではどうぞ

概要

だいたいこんな感じで、AWSやRuby/Railsをメインに情報を収集しています。後でそれぞれの詳細について解説しますね

  • なんやかんやでRSS
  • twitter
  • ruby-jpのSlackワークスペース
  • オハヨーAWS

なんやかんやでRSS

なんやかんやでまだ生き続けているRSSも購読しています。

重要度が低いものは、feedly で暇な時にチェックして、 重要度が高いものは、slackの自分の分報チャンネルに出るようにしています

slack に出るようにしているRSS

feedly で見ているRSS

twitter

速報性ではなんやかんやここが一番ですね。 自分のやっている分野の本を書いたり、アウトプットを良くしている人、AWSの中の人などを 350人ほどフォローして います。 AWS障害とか、最近だとLog4Shellみたいな大きなできごとがあると、話題が何度も上がってくるので、見落としが無いのが良いですね。

仕方ないですね!

ruby-jpのSlackワークスペース

ruby-jp.github.io

こちらも速報性は高いです。Ruby以外にも、AWSの障害やセキュリティインシデントなども話題になるので、Rubyのwebエンジニアやっていて必要なニュースは割とここでキャッチアップできます。あと、Rubyで開発している企業blogの更新を通知してくれるチャンネルもあるので、ここでの情報キャッチアップもなかなか良いです。(弊社LCLも参加しています!)

オハヨーAWS

twitter.com

AWSの中の人などがやっている、毎朝平日9時に開かれる twitter スペースです。前日に更新された内容を30分ですごい勢いでキャッチアップしてくれるのを仕事をしながら聞いています。各サービスについてどういう場合に使うものなのかとか、マイナーなサービスの場合、これはどういうものなのかも解説してくれるので、単に更新を見るよりも理解しやすくて、助かっています。

まとめ

現状はだいたいこんな感じで、Ruby/Rails/AWSの情報を集めています。収集先が多すぎても見なくなってしまいますし、少なすぎてもキャッチアップしきれないのでなかなかバランスが難しいですね。RSS以降の世代の人はどんな風に情報収集しているのか気になっています。ぜひ「自分はこうしているよ」とかありましたら教えていただければ幸いです。

それでは!

Access-Control-Allow-Origin の値を動的に設定するときには、Vary 'Origin' も設定する必要があるよって話

これの続き

blog.kasei-san.com

Access-Control-Allow-Origin の値を動的に設定する必要があるパターン

複数のオリジンからクロスドメインのリクエストを受けるサーバが Access-Control-Allow-Origin を返す場合、オリジンごとに異なる値を動的に返す必要がある。

  • 参考: Nginxの場合のこんな感じの設定を書く

gist.github.com

その場合、CDNが問題になる

途中にCDNが挟まってる場合、Access-Control-Allow-Originが、最初に来たオリジンのままで固定されてしまう。

これにより、Access-Control-Allow-Originの値と異なるオリジンからのリクエストがすべて、CORSエラーになってしまう。

その対策

レスポンスヘッダに Vary 'Origin' を追加する。

Vary とは?

キャッシュ時にURL以外に、キーとなるリクエストヘッダの値を決める設定。 例えば Vary : Accept-Language とすると、同じURLでも、言語ごとにキャッシュされるようになる。

んで、Vary 'Origin' の場合、Origin がキーになる。 Origin は、クロスドメインのリクエストを投げた場合に、元々のドメインが格納されるリクエストヘッダ。

そうすれば、複数オリジンからのリクエストごとに、異なる Access-Control-Allow-Origin を返すレスポンスをそれぞれキャッシュできる。

参考

developer.mozilla.org

developer.mozilla.org

developer.mozilla.org

Access-Control-Allow-Origin の値が ("*" ワイルドカードではなく) 具体的なオリジンであるレスポンスをサーバーが送信する場合、レスポンスには Vary レスポンスヘッダーに Origin という値を設定して、 Origin リクエストヘッダーの値によって値が変わることをブラウザーに対して示してください。

2021/09/30 から、OpenSSL1.0.x でLet'sEncryptの証明書を使っているところと接続できなくなる問題とEC2での対策方法

現象

$ echo|openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org
Verify return code: 20 (unable to get local issuer certificate)
  • OpenSSLを使っている、curl やRuby なども影響を受ける

原因

  • Let'sEncryptの証明書チェーンは、R3 --> ISRG Root X1 --> DST Root CA X3 となっている
  • この、DST Root CA X3 が 2021/09/30 に期限切れとなった
  • トラストストアには、ISRG Root X1DST Root CA X3 が入っているが OpenSSL 1.0.x では、 証明書チェーンの中に「トラストストアにあるが期限切れ」の証明書があると検証が失敗扱いになる という挙動がある

歴史的経緯

Let'sEncrypt がルート証明書を DST Root CA X3 から ISRG Root X1 に変更しようとする流れ

  • もともとの Let'sEncrypt のルート証明書は、DST Root CA X3
  • Let'sEncrypt は、ルート証明書を ISRG Root X1 に変えようとしていた
  • しかし、古いクライアントでは、トラストストアに、ISRG Root X1 が無いため、中間証明書を DST Root CA X3ISRG Root X1 のクロスサイン証明書にしていた(これにより、どちらかがトラストストアにあれば検証が通る)
  • その後、2021/09/30 に DST Root CA X3 の期限が切れるため、ルート証明書を ISRG Root X1 だけにする動きが始まる

Android7.1 問題と苦肉の策

  • しかし、Android7.1以前のバージョンにはISRGのルート証明書が入っていないため、ルート証明書を切り替えると、Android7.1以前でLet'sEncryptの証明書が使えなくなるという問題が判明
  • で、Let'sEncryptは苦肉の策として、以下のようにルート証明書を変更するとアナウンス
R3 --> ISRG Root X1 --> DST Root CA X3
  • ルート証明書の上にルート証明書をチェーンするという荒業
  • これをすると、Android7.1以前では、ISRGがトラストストアにないため、DSTまで遡る。ここで、2021/09/30 以降は、DSTの有効期限が切れてしまうが... Android7.1では、証明書の有効期限チェックを行わない ため、問題が解決すると... 解決...?
  • ISRGをトラストストアにもつ、他のクライアントではDSTまで遡らないため、特に問題はないはずだったが...

OpenSSL 1.0.x では Android互換チェーン の検証に失敗する

  • しかし、OpenSSL 1.0.x では、上記の「Android互換チェーン」については検証が失敗扱いとなる。これは、OpenSSL1.0.xで、信頼チェーンの間に無効な証明書があって、さらにそれがトラストストアに登録済だと、検証が失敗するという挙動(仕様?)のため

👇 Let'sEncrypt による、OpenSSL 1.0.x では Android互換チェーン の検証に失敗する件の記事

community.letsencrypt.org

  • OpenSSL 1.1.0 では修正済みで、1.0.x はたくさんの脆弱性があるので、さっさとバージョンをあげようとアナウンスしている

対策

OpenSSL公式は、トラストストアにて、期限切れのDSTのルート証明書を削除するようにと、アナウンスしている

https://t.co/bL7HmxKqcr?amp=1 www.openssl.org

AWS(EC2)では、ルート証明書のyumパッケージである ca-certificates にて、上記の対応を済ませたバージョンを配布しているので、yum update ca-certificates すれば解決する

aws.amazon.com

AWSでは、さらにこちらで手動対策方法もアナウンスしている

aws.amazon.com

参考

songmu.jp

songmu.jp

www.walbrix.co.jp