![http://blog.yoslab.com/entry/2014/03/05/192407](https://cdn-ak-scissors.b.st-hatena.com/image/square/38db676ee40fdd427a11ed409f457f8ae9b1456f/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fy%2Fyoshi0309%2F20140305%2F20140305191753.png)
HTTPプロキシを経由して ssh するにはconnectコマンドをProxyCommand指定すればいいと言うことが分りました 設定例 ~/.ssh/config 23 Host mm 24 Hostname ssh.example.com 25 ProxyCommand connect squid.example.com:3128 %h %p しかし、22番へのCONNECTを拒否するのがSquid squid のデフォルト設定は22番へのCONNECTを許可しません squid.conf # Deny requests to unknown ports http_access deny !Safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports と、SSL_Port以外の
API を IAM で認証する Amazon API Gateway (以下 API Gateway) で作成した API は、誰でも呼び出せるように公開する他に、2つの認証方法が用意されています。 API Key をヘッダーに付与する方法 (こちらで解説) IAM で認証する方法 この2つの方法のうち、今回は IAM で認証する方法を試してみたいと思います。 API Gateway にはモバイルアプリ向けの SDK を生成する機能がある点から、モバイルアプリを主なターゲットにしているように思えます。そこで、Amazon Cognito (以下 Cognito) を利用した認証方式を通して API Gateway で作成した API を呼び出してみたいと思います。 先日まで生成した SDK の認証周りでエラーが発生し Cognito (IAM Role) を利用した呼び出しが行えないことが
1度挫折したんですが、Node.js側からせめてサーバーサイドでも認証できました。 具体的なコードを(ほとんどコピーですが)以下のプロジェクトに上げました。 https://github.com/a-hisame/cognito-userpools-example cognito-idpのGetAuthenticationDetailsとAuthenticateをそれぞれ定義して使っています。 詳しくはプロジェクト内の feature-list-ja.md あたりを読んでみてください。 これで、 ユーザの生成(+確認用コード付き) ユーザのパスワードなどの再発行 ユーザの管理 アクティブユーザの閲覧 ユーザに紐付く一時IAMの発行 などがAWS Cognitoだけで完結できるようになりました *1。 すげぇ。 *1:厳密にはIAM RoleとかSTSとかをCognitoが使ってるけど、表面
はじめに こんにちは植木和樹@上越妙高オフィスです。今日はAmazon Linuxへのsshログイン時におけるセキュリティ強化のお話です。 AWS運用チェックリストではOSにログインする際のユーザーは共有せず、個人ごとにOSアカウントを作成することが推奨されています。 これからAWSを始める人は一読すべき「AWS運用チェックリスト」を読んでみた | Developers.IO 個人ごとにOSアカウントを作成すれば、いつ誰がそのサーバーにログインしたのか分かるので不正な操作が行われた際のトレースに役立ちます。 しかし仮にパソコンが盗まれる等で秘密鍵が盗まれてしまった場合を想定し、さらにもう一段階、その人のみが持っているものを用いなければサーバーにログインできない仕掛けを作ってみます。これを2段階認証といいます。今回は 1.個人のssh鍵ファイル + 2.スマホに表示されるワンタイムパスワード
onprepackの津村です。(※onprepack = 最近社内で流行ってる単語。) 地元のスーパーで柿が売られているのをみて、秋を感じています...。(しみじみ VPCのプライベートサブネットに、VPNから乗り込む。 最近はGoogleAppsやサイボウズをはじめとして、グループウェア製品は、インストールタイプからSaaSに移行しつつあります。 インターネット上から誰でもアクセスでき、サーバを用意する必要が無いSaaSでの提供は、ビジネス上のコストを上手に下げてくれる効果があります。 しかし、一方で会社によっては、秘伝のタレのごとくコードを継ぎ足し継ぎ足し作ったグループウェアから乗り換えられない(しかもスパゲッティでメンテできない)といった状況から、ミドルウェアの脆弱性やハードウェアの寿命を放置、もしくは場当たりのメンテナンスで延命している場合もあります。 例えば脆弱性のあるアプリケー
AWS VPN (1) between VPC VPN G/W and Debian Linux (racoon, setkey, quagga) with NAT AWSのVPCにはVPN機能がついているので、利用すると社内など任意のサブネットとVPCの間を、Privateアドレスで暗号化通信できるようになります。 通常このVPC VPNは、ハードウェアルーターを用いて接続するべく、一般的なルータの設定ファイルを配布してくれる至れり尽くせりな環境なのですが、ウチは貧乏でLinuxが大好きなので、 Debian Wheezyで接続を試みるのでした。 2つの方法 Linuxでは私が最初に構想した、綺麗で完全な冗長化構成はできないことがわかり、妥協案として2つの構成案ができたため、2つのエントリに分けて書くことにします。その2つの案とは、 綺麗な冗長化+NAT 泥臭い冗長化+非NAT で、まず
こんにちは、コカ・コーラが大好きなカジです。 下記ブログでAWS VPC VPN ConnectionsがNAT Traversal(NAT-T)に対応したことが発表されたので、VyOSを使ってNATルータ経由し、動的ルーティングでAWSとVPN接続をしてみましたので紹介します。(まあ、簡単に言うと自宅とAWSを動的ルーティングVPN接続しました。) EC2 VPC VPN Update – NAT Traversal, Additional Encryption Options, and More NAT Traversalについての詳細は、Wikipediaやここを参照ください。 構成図 AWS側 以前のVPN Connectionsの設定と全く変更ありません。 Virtual Private Gatewayを構築 VGWとVPCへのアタッチも忘れずに。 カスタマーゲートウェイを登録
はじめに こんにちは植木和樹です。AWSでは各種ホワイトペーパーなどの資料を多数公開しています。 AWS アーキテクチャーセンター | アマゾン ウェブ サービス(AWS 日本語) 今回は上記ページからダウンロードできる「AWS 運用チェックリスト(PDFファイル)」を読んでみました。運用チェックリストという名前ではありますが、AWSを利用する方は一度目を通しておくのをお勧めする内容でした。 チェックリストは大きく3つ「ベーシック」「エンタープライズ」「セキュリティ監査」に分かれています。このうちベーシックは15項目程とコンパクトにまとまっていて、簡易チェックリストとしてお手頃です。 残念ながらまだ日本語訳がされていないようですので、今回ベーシック部分だけをザックリ読んで簡単なコメントを書いてみました。 ベーシック運用チェックリスト 原文は「我々は〜〜〜を設定しています(理解しています)」
はじめに AWSのEC2にはSecurityGroupと呼ばれるファイアウォールがあります。"指定したIPアドレスから、特定のポートのみアクセスが可能"といった指定をすることでセキュリティを上げることができます。 ただ、会社のような固定IPを持った場所からのアクセスではよいのですが、モバイル機器などを用いる場合は毎回IPアドレスを指定するというのは非現実的です。というわけで、スクリプトをつくって省力化してみました。 sshをする前にSecurityGroupに自分の利用しているIPによるSSHを許可して、ssh終了後に追加したルールを削除するというスクリプトです VPNを使うのが本筋だとはおもいますが、いつもできるというわけではないので、役に立つ場合もあるかもしれません。 スクリプトの概要と実行結果 myssh.sh というシェルスクリプトを作ってみました。短かいコードですのでまずはコード
概要 AWS EC2 インスタンスの Public IP は起動毎に変わってしまい、 ssh や curl コマンドに与えるアドレスを毎回確認するのに困っていませんか? 特に常時起動しない検証や開発のための環境、 Auto Scaling に依存した環境と相性が悪いと思われます。 よくある手法1、EIP を付与する。 しかし EIP はインスタンス起動してない間に費用がかかり、頻繁に Stop したり新規追加するのに向いていません。 よくある手法2、 Route53 を利用する。 Route53 にインスタンスと対照になる名前を与え、 Lambda 等で定期的に更新すれば IP アドレスを意識せずに済みます。 しかし Public Hosted Zone の費用が掛かってしまいます。 Lambda 更新間隔や TTL でのタイムラグもあります。 よくある手法3、 AWS CLI を ssh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く