2015-04-11 #シス管系女子 #ハンズオン復習
https://github.com/piroor/system-admin-girl-handson/blob/master/system-admin-girl-handson.md#case3-1
上は昨日やったハンズオン資料。
時間切れで、この資料のケース３が実践できなかったのと、
“user”がどこのユーザなのか明確じゃなくて、少し手こずったけど、たぶんこういうことか。
もし間違えていたら、ツッコミください＞だれか。
＝＝＝目標＝＝＝
NATルータ配下に存在する、ポート開放していないサーバに、中継サーバ経由でssh接続する。
＝＝＝環境＝＝＝
※名前は解決できている物とする
●ホスト名
backendhost: NAT配下の最終目的地サーバ。インターネットの向こうにある。
サーバ側からはインターネットにつながる。
relayhost : グローバルIPを取得している中継サーバ。インターネットの向こうにある。
backendhost とは、別のネットワークに属している。
localhost : NAT配下の手元にある操作端末。
インターネットにつながる。
●ユーザ名
backuser : backendhostに作成されているユーザ名
relayuser : 中継サーバに作成されているユーザ名
localuser : 手元の操作端末に作成されているユーザ名
●ポート
22 : backendhost が待ち受けるポート。最終的に到達するポート
20022 : relayhost から backendhost に転送される待ち受けポート
10022 : localhost から relayhost の 20022 に転送される待ち受けポート
＝＝＝手順＝＝＝
１．SSH リモートフォワード ( backendhost で実行 )
中継サーバに、backendhostの22番に転送する待ち受け用のポートを作成する。
$ ssh relayuser@relayhost -R 20022:backendhost:22
２．SSH ローカルフォワード ( 手元の操作端末で実行 )
手元の端末に、10022に接続すると、中継サーバの 20022 ポートに投げるポートを作る。
$ ssh relayuser@relayhost -L 10022:localhost:20022
※ ここで示している localhost は、「relayhost からみた localhost アドレス ＝ relayhost の ループバックアドレス」
３．
別窓で、backendhostに接続する。（※項番1と2は実行したまま）
$ ssh -p 10022 backuser@localhost
※ ここで示している localhost は、手元にある操作端末からみた localhostアドレス。
＝＝＝課題＝＝＝
●課題
リモートポートフォワードが自動で作られるか、tunnelが崩落しても再構成してくれる仕組みを考えておかないと、使いたい時に使えない。
●問題点
試していないけど、たぶん問題点というかリスクとして、relayhostの20022にアクセスできる人はだれでも、backendhost の 22 まで到達してしまう。
●不明点
公開鍵交換式認証の場合、どこの鍵をどこに置けばいいのか、いまいちわからない。
課題がクリアしたら、またpostするかもしれない。
こちらに書かれている通りの内容で間違いないです！
ユーザー名等の所では、配慮を怠ってしまっていました……確かに、各ホストのユーザー名は分けておいた方が分かりやすかったですね。リモートフォワードの実践でも、今自分がどこにいるのか？が分かりにくいせいでうまくいっていなかった方が多かったようですし。
> ●課題
> リモートポートフォワードが自動で作られるか、tunnelが崩落しても再構成してくれる仕組みを考えておかないと、使いたい時に使えない。
説明をカットしてしまいましたが、autosshを使うといいと思います。これなら、自動で再接続してくれます。
> ●問題点
> 試していないけど、たぶん問題点というかリスクとして、relayhostの20022にアクセスできる人はだれでも、backendhost の 22 まで到達してしまう。
これも説明しなかったのですが、実は初期状態のsshdでは、リモートフォワードの場合もローカルフォワードの場合も他のホストから直接送られたパケットは転送しないので、このリスクはありません。
ローカルフォワードの場合は手元のPC自身からlocalhost宛に送られたパケット、リモートフォワードの場合は20022番ポートを待ち受けているrelayhost自身からlocalhost宛に送られたパケットだけが転送されます。
また、ConoHaのVPSの場合は初期設定で22番ポートのみが開放されているため、20022番ポートには外部からは到達できません。
なので、そもそもrelayhostにログインできる権限がある人でなければ、このトンネルは通れないのです。
（逆に、トンネルを他の人にも使わせるためには、ポートの開放と、sshdでのGatewayPortsの設定変更が必要です。）
> ●不明点
> 公開鍵交換式認証の場合、どこの鍵をどこに置けばいいのか、いまいちわからない。
これも話がややこしくなるのでカットしてしまった部分でした。
基本的に秘密鍵をあちこちに置きまくるのは宜しくないので、秘密鍵はこの例だとbackendhostとlocalhostの2箇所だけに置いておき、各中継点でのログイン時にはssh-agentを使って認証情報を引き継ぐのが良いと思われます。
鍵認証を使うとなると、説明時にssh-agentの説明を含めるか、もしくは各ホストに秘密鍵を置かないといけないことになってしまって、それは却って危険なので、今回の説明ではこんな感じにした次第でした。
リモートフォワードの事例は過去に会社のブログでも書いたので、参考にしていただければ幸いです。
http://www.clear-code.com/blog/2014/9/12.html
さっそく先生から コメントが！Σ(･ω･ﾉ)ﾉ
ありがとうございます。
コマンドや、ユーザ名が間違えていないとのことで、よかったです。
今回、ぼくが復習に使った環境が、backendhostに自宅サーバ、relayhostにレンタルサーバを用いていて
レンタルサーバはVPSではなく共用サーバとなっている環境でした。
ですので、relayhost には、複数ユーザがログインできる状況となります。
その状況でも、GatewayPortsの設定がなければ（デフォルトであれば）問題ないということですね。
また、autossh と ssh-agent 、また、blog の紹介もありがとうございました。
ぜひ参考にさせていただきます。
> ですので、relayhost には、複数ユーザがログインできる状況となります。
おお……であれば、backendhostは鍵認証専用にしておくなど、それなりに気をつけないといけないですね。
例えば僕のように「relayhostにHTTPでリクエストを送ることはできる」というような人からのアタックを気にするという点では、GatewayPortsの設定やポート開放などが行われていない限りは安全と言えますが、自分が信用できる人以外もrelayhostにログインする可能性があるのであれば、そのような人達による20022番ポート経由でのbackendhostへのアタックを警戒しないといけないので。
やはり、信頼できない第三者がsshログインできる場所では、むき出しで置いてあるよりはマシとはいえ、考慮が必要なのですね。
ありがとうございました。大変勉強になりました。
ところで、このエントリの手順２の、localhost は、
「 relayhost にとっての localhost アドレス」ですね。
用例が適切ではありませんでした(-_-;)
まだ理解が浅いので、登場人物が多くなると混乱してしまいます。