まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:ssh

(一部で?)話題の serveo サービスを使ってみました。

serveo は http://localhost:XXXX で稼働するウェブサービスを https の固定URLで公開するサービスです。加えて無料で、しかも(ssh が導入済みであれば)ツール類のインストールは不要です。なお以下の作業は Windows 10 の WSL(Ubuntu 18.04) 環境を使って行いました。macOS や Linux, Raspberry Pi などを使う場合でも同様のはずです。

どのように使うかを以下で紹介しますが、今回は例としてこのウェブアプリケーションをネット公開してみることにします:
https://github.com/dotnsf/keytouch_sample

2019080702



「キーボードから入力されたキーをそのまま画面に表示する」という Node.js のウェブアプリケーションです。Node.js が導入されていればローカル環境で稼働させることができます。

実際に動かすには上記リポジトリからコード一式を git clone またはダウンロード&展開して、npm install して app.js を実行します(緑字は出力されるメッセージです):
$ git clone https://github.com/dotnsf/keytouch_sample

$ cd keytouch_sample

$ npm install

$ node app
server starting on 6022 ..

実行すると空きポートを見つけてリクエストを待受ける状態になります。上記例では 6022 番ポートで稼働しています。

このアプリケーションを使うには、ウェブブラウザで http://localhost:6022/ へアクセスします(6022 の部分は実際に稼働しているポート番号を指定してください):
2019080701


↑キーボードを適当に叩いて入力すると、叩いたキー文字が画面に表示される、というだけのアプリケーションです(英文字や数字は正しく表示されると思いますが、一部の記号には対応していません)。

では、この localhost で稼働中のアプリケーションを serveo を使って公開してみます。別のターミナルを開いて、以下のコマンドを入力します(6022 の部分は実際に稼働しているポート番号を指定します):
$ ssh -R 80:localhost:6022 serveo.net
Forwarding HTTP traffic from https://ledo.serveo.net
Press g to start a GUI session and ctrl-c to quit.

実はたったこれだけです。上記例では https://ledo.serveo.net にフォワードされる、というメッセージが出力されています。実際にウェブブラウザで(可能であれば別のマシンのウェブブラウザで)指定された URL にアクセスしてみると、実際に稼働していることが確認できます:
2019080703


こんな簡単に、しかも https の固定 URL でウェブサービス公開ができてしまいました。驚き!

ちなみに、このサービス自体は SSH のフォワーディング機能だけで実現しているようで、上記コマンドの "localhost" はローカルホストでなくても構いません。なので(ホスト名が変わることが問題にならなければ)http で動いているサービスを簡単に https 対応させることもできそうです。

その他、コマンドのオプション等は公式ページに詳しく紹介されているので参照ください。いやそれにしても便利なサービスだ。自分で作ったアプリがここまで簡単にウェブ公開できるとは・・


自分メモ兼情報緩募なブログエントリです。

SSH でサーバーにリモートログインして作業している途中で通信が途切れてしまう(プロセスが死んでしまうわけではなく、通信が切れてしまう)ケースがあります。自分が比較的頻度高くやっちゃうのは、電車内からテザリングを使ってリモートログインした先で Node.js のサーバーを動かしていて、地下鉄に入って通信が遮断しちゃうケースです。

これをやってしまって困るのは、例えば Node.js のサーバーを 8000 番ポートで動かしていたとすると、8000 番ポートへの listen が生きたままの状態で通信が切れてしまうことです。繋がっていれば Ctrl+C でサーバーを落とすことができるのですが、繋がっていないので Ctrl+C を入力する端末がありません。ということは再度リモートログインしてプログラムを修正して再度実行・・・しようとしても「そのポートは使われています」エラーになってしまいます。なんとかして元のプロセスを止めなければなりません。


※余談ですが、本来はこうならないように(途中で通信が切れてしまうことを想定して) screentmux などの端末のマルチプレクサーを使って作業するべきです。ただ今回はマルチプレクサーを使っていない時にこうなってしまった場合の対処方法についての話です。


以下で紹介する方法が正解かどうかはわからないのですが、自分の対処方法を紹介します。考え方としては「プロセスが残っているはずの SSH を探し出して息の根を止める」というアプローチです。

というわけで、まずは再度リモートログインした先で ps コマンドを実行して、自分が所有しているプロセスを一覧表示します(ちなみに実行コマンド内で `whoami` を実行していますが、自分の環境だとこの結果は dotnsf となり、dotnsf という文字を含むプロセスの一覧を表示しています):
$ ps -aux | grep `whoami`

root      4335  0.0  0.0  94924  7092 ?        Ss   08:19   0:00 sshd: dotnsf [priv]
dotnsf    4410  0.0  0.0  94924  4428 ?        S    08:20   0:00 sshd: dotnsf@pts/8
dotnsf    4411  0.0  0.0  23912  5620 pts/8    Ss   08:20   0:00 -bash
dotnsf    4654  0.0  0.5 935364 41736 pts/8    Sl+  08:37   0:00 node app
root      5167  0.0  0.0  94924  6964 ?        Ss   09:20   0:00 sshd: dotnsf [priv]
dotnsf    5243  0.0  0.0  94924  3408 ?        S    09:20   0:00 sshd: dotnsf@pts/9
dotnsf    5244  0.1  0.0  23800  5392 pts/9    Ss   09:20   0:00 -bash
dotnsf    5270  0.0  0.0  38376  3392 pts/9    R+   09:21   0:00 ps -aux
dotnsf    5271  0.0  0.0  15256  1012 pts/9    S+   09:21   0:00 grep --color=auto dotnsf
dotnsf   23891  0.9  1.4 1661748 118288 ?      Sl    2月23 651:40 /opt/couchdb/bin/../erts-7.3/bin/beam.smp -K true -A 16 -Bd -- -root /opt/couchdb/bin/.. -progname couchdb -- -home /opt/couchdb -- -boot /opt/couchdb/bin/../releases/2.0.0/couchdb -kernel inet_dist_listen_min 9100 -kernel inet_dist_listen_max 9100 -kernel error_logger silent -sasl sasl_error_logger false -noshell -noinput -config /opt/couchdb/bin/../releases/2.0.0/sys.config
dotnsf   23940  0.0  0.0   4512   856 ?        Ss    2月23   0:00 sh -s disksup
dotnsf   23941  0.0  0.0   4232    72 ?        Ss    2月23   0:05 /opt/couchdb/bin/../lib/os_mon-2.4/priv/bin/memsup
dotnsf   23942  0.0  0.0   4364    76 ?        Ss    2月23   0:00 /opt/couchdb/bin/../lib/os_mon-2.4/priv/bin/cpu_sup
dotnsf   26173  0.0  0.0  45276  3140 ?        Ss    2月15   0:00 /lib/systemd/systemd --user
dotnsf   26174  0.0  0.0 210940  2152 ?        S     2月15   0:00 (sd-pam)
dotnsf   31713  0.0  0.0  11140   312 ?        Ss    3月30   0:00 ssh-agent
  (↑青字が実行コマンドです)


結果の中で注目すべきは赤字にした2行です。dotnsf が sshd から pts(仮想端末)を使っているプロセスが(左から2列目の数値でいうと) 4410 と 5243 の2つあります(実際にコマンドを実行した結果は3つ以上みつかるかもしれません)。この2つのうち、どちらかは今自分がリモートログインに使っている仮想端末のプロセスで、もう1つは今回のターゲットとなる行方不明のプロセスです。このどちらか正しい方のプロセスを kill することで目的を達成することができます。

というわけで、「どちらかは正解、間違えると自分が死ぬ」という下図のような状況なわけです(笑):
jigenbakudan_kaitai_shifuku




ここでの問題は「どちらが目的のプロセスかを判断する方法」なのですが、これって正解あるんでしょうか? (^^; 明確な方法があったら自分も知りたいです。

自分がやっている判断方法としては2つあります:
・時刻(左から9列目)を見る。どちらかは自分がログインしているプロセスということは、そのプロセスの時刻は自分がログインした時刻になっているので、自分が現在ログインしているプロセスをなんとなく判断できる。
・プロセス番号(この例だと 4410 と 5243)は大抵小さい方が古い。現在のログインに使っているプロセスの方が新しいはず。


で、この基準で考えるとプロセス番号 5243 の方が現在使っているプロセスに該当するので、もう1つの 4410 のプロセスが息の根を止めるべきプロセス、と判断できることになります。ただこの考え方は経験的なもので、もしかすると別の確実な方法があるかもしれません(誰か知っていたら教えてください)。


(↓追記)
who コマンドで自分が現在いる TTY を調べることができる、という指摘をいただきました。確かに使えそうです。
$ who
dotnsf   pts/8        2018-04-12 21:00 (192.168.X.X)

(↑追記)


というわけで、4410 を kill することにします:
$ kill 4410

まあ仮に間違えていたとしても自分が強制ログアウトされるだけなので、そしたらもう一度リモートログインしてもう1つの方を kill し直せばいいんですけどね。。

で、これで上手く元のプロセスを消すことができていれば、再度実行した時に「そのポートは使われています。。」エラーは消える、はず。

 

先日、Bluemix 上で使えるようになった WebSphere Application Server (以下 WAS for Bluemix)についてこちらで紹介しました:

上記記事では OpenVPN を使って WAS for Bluemix のサーバー 仮想マシンと VPN 接続をして、WAS のウェブコンソールにアクセスする、という手順を紹介しました:

 

WAS for Bluemix 環境では、上記のウェブコンソールにアクセスするだけでなく、サーバー仮想マシンに ssh 経由でログインしたり、そこから root になって管理者権限で OS を利用することも可能です。今日はそちらの手順を紹介します。

まずは準備として WAS for Bluemix の仮想マシンに対して OpenVPN を使った VPN 接続までは済ませておいてください。具体的な手順は上記リンク先を参照してください。

次に Bluemix 内に定義した WAS for Bluemix のサービスを開いて、VPN 構成ファイルをダウンロードしたこのページを開き、仮想マシンの左横にある下向きの矢印部分(数の赤枠部分)をクリックします:
2016021201


すると隠れていた部分が展開されて、この仮想マシンに SSH 接続するために必要な情報が表示されます:
2016021202


WAS for Bluemix の仮想マシンに SSH 接続するには RSA の秘密鍵が必要です。「鍵の保存」でダウンロードするか、または「鍵を表示」で確認した内容と同じテキストファイルを SSH を実行するクライアント機上にファイルとして用意します(用意したファイルのパーミッションを 600 などにして、他人がアクセスできないようにしておきます):
2016021203


これで SSH 接続のための準備が整いました。以下のコマンドで SSH 接続します(WAS 仮想マシンへの SSH 接続時のユーザーは virtuser を指定します):
$ ssh virtuser@(WAS for Bluemix の仮想マシンのIPアドレス) -i (保存した鍵ファイルのファイルパス)

自分が確認した限りですが、正しい鍵ファイルが指定されていればパスワードなしでログインできます。ユーザー名は上記で指定した virtuser になっていますが、sudo 権限があるようなので、ログイン後に root に切り替えて操作することも可能です:
2016021204


root でログインできる SSH サーバーが提供された、ともいえます。ディレクトリ構成とかを見る限り、ベースはどうも RedHat Enterprise Linux っぽいようにも見えますが、まあその辺りに興味ある方はいろいろ調べてみてください。


ペネトレーションテスト向けにカスタマイズされた Linux ディストリビューションである『Kali Linux』。いろいろアレな機能が標準搭載されていることに加え、見た目もカッコいいし、LibreOffice とかも入れれば普段使いのデスクトップ環境としても使える、という印象を持っています:


なお Kali Linux の導入手順および日本語化他については以前に作成した以下のエントリを参照してください:
Kali Linux を使ってみる


デスクトップ環境が目の前に使える状態になっていると便利なのですが、ペネトレーションテスト用のこだわりなのか、一般的な Linux ではデフォルト状態で使えるサービスの多くが使えません。例えば sshd も無効なので SSH によるリモートログインなども無効になっています。

これはこれでちょっと不便に感じることもあるので、Kali Linux で sshd を有効にする方法を紹介します。手順は簡単で、root でログインして以下のコマンドを実行します:
# update-rc.d ssh enable

で Kali Linux を再起動すると sshd が有効になっており(というか、自動で起動するようになり)、SSH によるリモートログインもできるようになります。


 

IBM がビジネスパートナー企業様向けに無料で Power アーキテクチャのサーバーの試用を提供しています。1回につき2週間程度なので、長期利用を前提とする使い方はできませんが、アプリケーションの Power 上(RedHat Enterprise Linux や Ubuntu の Power 版、AIX, i/OS など)の動作確認や互換性チェックなどを行うには充分だと思っています。利用前に企業登録などの手続きの必要はありますが、料金が発生することはありません。 この PDP(Power Development Platform) と呼ばれるサービスの利用方法については過去にこのブログでも何度かとりあげています。RHEL での紹介ですが、興味ある方はこちらも参照ください:
Power 版 RHEL(RedHat Enterprise Linux) を無料で2週間借りる

実はこの PDP 上の RHEL 環境を使っていて、少し気になることがありました。サーバーリソースがアクティブになり、VPN も張り、いざ SSH でリモートログイン! ・・・しようとすると、結論としてログインできるのですが、SSH コマンドを実行してからパスワードを聞かれるまでに、やけに時間がかかるのです:
2015061001

結論としてはログインできるんだけど、SSH を実行してからパスワードプロンプトが表示されるまでに1分くらいかかってしまいます。それまではパスワードを入力したくてもできない。 で、待ってる間に別の作業でも・・・と思ってメールとか見ていると、いつの間にか夢中になって5分くらい過ぎて、パスワード入力もタイムアウトになってログインに失敗しているという(苦笑)。

RHEL 以外の環境で同様のことが発生するかは試していないのですが、どうやらこれは sshd の認証設定によるものなので設定を変えれば回避できそうです。具体的にはこちらで紹介している対処方法でいけます:

↑こちらで紹介している手法にしたがって、最後に sshd をリスタートしておけば、それ以降の SSH アクセスではすぐにパスワードを聞いてくるようになりました。 PDP 上の RHEL を使っていて気になる方は参考にしてください。



このページのトップヘ