So-net無料ブログ作成
検索選択
2017年02月| 2017年03月 |- ブログトップ
前の10件 | -

SSHダメなプロキシを越えて、Linuxの端末操作してみる。3 Wettyを少しいじる [Linux]

職場からSSHをつなげなくて自宅マシンにつないで遊びたいLinuxの検証などをしたい人のために、Wettyを使おうシリーズ第三弾。まぁWettyを探して立ち上げたってだけの話なんだけど、SSHをフィルタリングされて通れないというパターンはたくさんあると思うので、それをHTTPSで通れるよということが分かるだけでも、困難が緩和されるってのものです。さすがにHTTPSを通さないプロキシはないと思うし、特定のURLをフィルタリングしているものだって、Dynamic DNSを通さないってのはなかなかないと思うし。

とにかく、前回まではオレオレ証明書で運用して外から見えたところまでやったのでした。せっかくletsencryptで証明書を取ってきたのに使ってないのでした。今回は使います。使ってはみたのですが、そして動いてはいたのですが、いまいち操作に確証が持てなかったので書きませんでした。でも、同じことをやっていた人がいたので、一応晒すことにしました。と言ってもリンク先と大して変わらないんですけど。

http://www.utali.io/entry/2016/11/21/025555

privkey.pemとcert.pemを使うだけなんだけど、それまでの経緯は以下。

http://miff.blog.so-net.ne.jp/2017-03-15-2
http://miff.blog.so-net.ne.jp/2017-03-21

sudo node app.js --sslkey /etc/letsencrypt/live/foo.bar.jp/privkey.pem --sslcert /etc/letsencrypt/live/foo.bar.jp/cert.pem -p 443


sudoにするのは443ポートで動かさないといけないのと、。.pemファイルがルート権限じゃないとアクセスできないからなので、sudoで動作させる。基本、80番ポートでもWellKnownポートだから、Webサーバは管理者権限で動かさないといけないのは、知らない時は覚えておいた方がいいです。まぁ作り付けのWebサーバを使っているとか、1024番以上のどうでもいいポートを使っているのであれば問題ないですが。


これがprivkey.pemを晒すことにならなければいいなと思うが、動作的に問題ないようなのでたぶん大丈夫。他のサイトでも同じような事をやっておったわけだし、それほど疑いがあるものでもないのかもね。というか、プライベートキーが流出しても、元々タダで得られたものだし、ダメな時はもう一回得ればいいだけかもしれんし。最悪、Dynamic DNSのURLを取り直せばいいような気もするし、そこまで気にしない。

変えたんだけど、自宅のサーバにLANからhttps://192.168.0.200みたいにアクセスしても、証明書が正しくないとされる。これはURLじゃなくてプライベートIPでアクセスしているからで、同じLAN内からではDynamic DNSのURLが使えないので仕方がない。





これでオレオレ証明書じゃなくて問題なくHTTPSにアクセスできるようになりました。あとはルートアクセスしてきた時に入られちゃう問題を解決しないといけない。というか、webrootがアクセスできないとか画像アップサイトじゃないんだからねぇ。でも、IPで適当にアクセスしてくるボットやハッキングに対しては、ルートを適切に処理しておくことが大事かと思う。これはExpressを使ってソースに手を入れないといけない。

https://github.com/krishnasrinivas/wetty/blob/master/app.js

ここにしか手を入れない。

app.use('/', express.static(path.join(__dirname, 'public')));


の前に

app.get('/',function(req, res, next) { res.send('hello');});


を置いておくだけで、Webルートからアクセスできなくなる。それだけでいくらかセキュリティは上がる。

更に「/wetty/ssh/ユーザー名」でアクセスできるんだけど、気になるならwettyのところを別のパスに切り替えてみれば万全。まずアクセスされることはないかもしれない。まぁ途中で盗聴できたらURLを取ること自体はHTTPSでもできるのかな? アクセスするURL自体は暗号化できそうな感じはしないけど、それでも安全性は普通の第三者から考えれば非常に高くなる。少なくともsshでアクセスできるポートを変える以上の効果はある。

ただ、これをやると/wetty/ssh/ユーザー名でしか、たぶん入ることができなくなるので、ルートからとか/publicから入るのはつぶされる。使い慣れてきてからやった方がいいのかもね。そんなこんなで、全三回でお送りしたWETTY動かして安全端末アクセスができたのでした。

タグ:Node.js
コメント(0) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2017/03/25 [Twitter]


コメント(0) 

Twitterまとめ投稿 2017/03/24 [Twitter]


コメント(0) 

Twitterまとめ投稿 2017/03/22 [Twitter]


コメント(0) 

SSHダメなプロキシを越えて、Linuxの端末操作してみる。2 WettyをHTTPSで使ってみる。 [Linux]

前に職場のプロキシでSSHが越えられずに困ったという話をして、それならばHTTPで端末操作ができればいいのではないかと思っていた。コマンドを渡して実行するってのは簡単だしやったことがある。まぁ色々セキュリティに問題があるのだが、そこはHTTPSを使うしかないのかなというところです。

そんなわけで、SSL/TLS用の証明書を無料で取ってこようという話になります。今はタダで配布しているという事なので、それをもらってきて使ってみる段階です。最終的にはnode.jsのアプリであるWETTYに適用する予定。

もはや定番になっているっぽいLet's Encrypt

https://letsencrypt.org/

でUbuntu用の証明書をアップデートするシェルスクリプトがあるらしく、aptで入れられるらしい。

https://certbot.eff.org/#ubuntuxenial-other

これかな?
sudo apt install letsencrypt

やたらPythonの依存パッケージが入れられて気持ち悪い。Pythonはバージョン問題などあんまり好きじゃない。コマンドの例を見てみると

$ letsencrypt certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is

そもそもDNSでURLがないとダメだよね。どこかのDynamic DNSでURLをもらってこないとな。ルーターとかNASによっては半自動的に付与されるのもあった気がする。というか、Dynamic DNSとか久しぶりなんだけど。前に探したのはずいぶん前だから改めて探し直さないとダメだろうね。

それと-dオプションのthing.is, m.thing.isってなんだろう。前の-dはexample.comで容易にURLドメインであることが分かるんだけど、後のは何だろう。同じ-w, -dの組み合わせなのはわかるんだけど…

https://blog.apar.jp/linux/3619/

バーチャルホストがうんぬんと書かれているのであんまり気にしないでいいかもしれない。


とりあえず、Dynamic DNSを登録してくる。なんかあれってプロトコルがあるようでない感じだったような気がするんだよね。RFCで決められているんだっけ? まぁURLと動的なIPを結びつけているだけだしねぇ。とりあえずお気楽な方法で。

DynamicDNSに登録してきた。
http://www.ieserver.net/
ってところで、IPを設定するのがシェルスクリプトを叩くだけで簡単そうだったので決めました。
ググったらもっと上に

http://www.mydns.jp/

があったんだけど、Ban4IPとか面倒くさそうだったのでやめました。でも、後から読んだら二行くらいのスクリプトで対応可能だったので、そっちを使えばよかったかもなぁと思ったり。まぁ気になったらそのうち移るとして。


登録したURLがhoge.foo.jpとして書きますが(実際にあるかもだけど…)、以下のコマンドでエラーが出ました。

letsencrypt certonly --webroot -w /home/hoge -d hoge.foo.jp

エラーでいろいろ出たけど

Detail: DNS problem: NXDOMAIN looking up A for

うんちゃらかんちゃら、と出ていて、よく意味が分からない。Webサーバを立ち上げないといけないのかなと思ったら、立ち上げたら立ち上げたで別のエラーが出て立ち上げるのやめろと出る。その前にルーターの設定で自分のサーバの80番ポートと443番ポートをつなげておいた。一応やっていることは外にはつながっているっぽい。


DNSサーバが悪いのかな、まだ登録されていないのかな、と思って一晩放置したのだが、一応スマホのLTE回線から見られるようにはなっていた。

結局、コマンドが違っていた。

letsencrypt certonly --standalone -d hoge.foo.jp

これで

/etc/letsencrypt/live/hoge.foo.jp/fullchain.pem

あたりに出てくる。でも、期限が短いって話なんだよなぁ。どうするんだろ。


同じディレクトリにはいくつかあるが、どれ使うんかな。

cert.pem chain.pem fullchain.pem privkey.pem

cert.pemあたりを使う気がするんだけど、メッセージにはfullchain.pemが出てくるので気になる。あとで調べよう。でも後でって言ったのって大体はやらないことが多いんだよなw。まぁオレオレ証明書でも動くことは動くからいいのだけれど…。


openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30000 -nodes

で出力して

node app.js --sslkey key.pem --sslcert cert.pem -p 3000

で動かせと書いてあるのでやってみると、やはりワーニングが出る。まぁ個人利用ならこれでもいいんじゃないでしょうか。やってないけど、cert.pemは同じとして、key.pemにあたるのがprivkey.pemでいいのかなぁ。privkeyってprivateなキーなんだろうから外に晒すようではだめなんだろうけど、これもletsencryptの仕様を調べてから使おうと思う。

現状では80番ポートで晒すとすぐにアクセスが来ていたから、最低443ポートでHTTPSで晒さないといけないな。そしてWebルートなURLでアクセスできちゃっているので、それをアクセス禁止にしてユニークなURLでアクセスするようにしないといけないだろうね。そうすれば、途中で盗聴してでもしなければ、アクセス方法はわからないし、URLが分かったところで基本的にユーザーとキーワードの認証はそれほど楽に突破できるものでもないでしょう。

普通の端末接続は、あんまり間違うとしばらく受け付けなくなるんだが、wettyではそこまでやってくれるかどうかはわからない。とりあえずDynamic DNSでURLを取らないと使えないのはまともなHTTPSを使おうとしたときには必要なので事前に取っておきましょう。以下次回。ソースに手を入れないといけないのでここまでにしておきます。

タグ:Node.js
コメント(0) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2017/03/20 [Twitter]


コメント(0) 

Twitterまとめ投稿 2017/03/18 [Twitter]


コメント(0) 

Twitterまとめ投稿 2017/03/17 [Twitter]


コメント(0) 

Twitterまとめ投稿 2017/03/16 [Twitter]


コメント(0) 

SSHダメなプロキシを越えて、Linuxの端末操作してみる。1 [Linux]

So-net blog自体のアクセスランキングは悪くないけど、パソコン・インターネットのカテゴリのランクが下がり気味。あんまり相関はない感じなんだよね。まぁ普通は今の時期は年度末なので忙しいのだけれど、カテゴリ的に仕事中にやってるやつとかが多いみたいで、お気楽でいいねぇと思わざるを得ないのだけれど。


と愚痴っぽいのはそれくらいにして、仕事でのLinux利用。職場はファイヤーウォールだかプロキシサーバだとかで、SSHが通らない。ポートを色々設定したのだが、そもそも受け付けてないっぽいのだ。どこかにHTTPでつなげる端末とかないかなと思ったら、Webサーバ経由でターミナル操作できるものがあるみたい。

これとか
https://www.npmjs.com/package/web-terminal
これとか
https://github.com/krishnasrinivas/wetty

後者の方がターミナルとしては優れているっぽいので、wettyにしてみる。なんか名前が湿ってる感じがするけど、もともとwettyという単語はないらしい。wetで形容詞だし。

HTTPSも使えそうなので、あとあとそのためにソースに手を入れなくていいっぽいね。オレオレ証明書でしかSSLを使ったことがないので、今回はLet's encryptを使ってみたい気はしている。というか、暗号化しないでユーザー名とパスワードを送るのなんで無理。

http://knowledge.sakura.ad.jp/knowledge/5573/

node.jsでWebサーバをいじったことがあるので、Webルートで動作するところを変えないとクラッカーの餌食になりそうな予感。というか、アクセスログを見たことがあるのだけれど、適当にIPアドレスで来ているのってたくさんあるんだよね。んで、ありそうなURLのパスでアクセスしようとして来ていたりしている。まぁそういうのはほとんどボットなんだろうけど、踏み台にされるのはまっぴらなのでなんとか考えたいところである。


まずLXCでサーバ作ろうか。Ubuntuでいいか、面倒だし。と思ったけど、外につなぐ時にポート開けたりしないといけないだろうからやめて物理サーバに。まぁ物理サーバにつないでからLXCコンテナ作ってもいいや。

というわけで、物理サーバのUbuntuにnode.js、npm、wettyという手順で入れる。

めんどうなのでnode.jsはUbuntuリポジトリで
sudo apt install nodejs

あ、入ってた。バージョンはv4.2.6で対応しているかどうかは怪しい。
sudo apt install npm

んでwettyインストールはサイト通りに。
git clone https://github.com/krishnasrinivas/wetty
cd wetty
npm install


deprecatedが4つ出て、そのあとにエラーが出た。ん〜なんだろう。二年前のソースだからそんなに問題になりそうな感じはないだろうなぁ。

node-gypあたりでエラーが出ていて
node-gyp rebuild
としても解決せず。WindowsだとPythonの環境の問題で必ずと言っていいほど出まくっているみたいですが、Ubuntuだしなぁ。

sudo npm install -g node-gyp

入れ直してもpty.jsがnode-gyp rebuildしろというのは変わらない。




挫折してちょっとweb-terminalの方にちょっかいを出してみる。
sudo npm install web-terminal -g
ですんなり入る。本当はsudoしたくないんだけど、ダメらしいので。
web-terminal --port 8088
で起動。どこに入っているのかさえも分からないけど、あっさり。

それでクライアントPCからhttp://192.168.0.123:8088とかでアクセスすると少し間をおいてプロンプトが出る。
~/.npm/web-terminal/0.7.0/package
からなぜか入るのだが、ここにはバイナリとかの実態がない。node.jsだからテキストか。

$ which web-terminal
/usr/local/bin/web-terminal

みたいな感じでコマンドは打てる。でもviとかはダメだって書いてあったな。単純なコマンドラインのみっぽいけど、viを立ち上げてみる。わーw
web-terminal-vi.png
なんかぐちゃぐちゃ出てきてテキストの編集どころではありませんでした。やっぱり、wetty立ち上げ頑張らな。




色々やってみたので決定打となるコマンドが分からないんだけど、大体こんな感じで直った。

npm update -g npm
npm update -g
node-gyp clean
node-gyp install
node app.js -p 3000

npmとその中のパッケージを新しくする。
node-gypコマンドでコンパイルした内容をきれいにしてから、新しく入れ直す。
そんな感じなのかな。

正直npm周りが分からないので、新しくしてみたら何とかなった次第です。たぶん結構前に入れたので、使うときには新しくしましょうというのが鉄則なのでしょう。それから対応するバージョンに合わせていくのが無難なのかと。基本、安定板の一番新しいのを入れるのがいいんでしょうが、色々問題はありますしね。

とりあえずviが動く環境を手に入れられた。次はSSLというかTLSでHTTPSにしたい。オレオレ証明書でもいいけど、タダでもらえる時代なのでガチで入れてみる。あとWebのルートディレクトリで動作させるのは危なすぎるのでこれも次にやろうと思う。プロキシの設定の問題で、80と443番ポートのアクセスしか受け付けないみたいなんだよね。怪しいポート番号は怪しいサイト、とみなしているのでしょう。どっちにしてもルートで動かさないといけないよなぁ。面倒だがやるしかないなぁ。

タグ:Node.js
コメント(0) 
共通テーマ:パソコン・インターネット
前の10件 | -
2017年02月|2017年03月 |- ブログトップ