A Day In The Boy's Life -134ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

週末なので企画ネタみたいなことをやってみる。


ネットと長く付き合っていると、そこで様々な出来事に出くわします。

うれしいものもあれば、悲しいもの、怒りを感じるものなど、その出来事によって受ける感情はさまざまなですが、やっぱりうれしい出来事はいっぱい起きてほしいものですよね。

自分なりに、ネットで起こったうれしい出来事や変化というものをあげてみました。



ネットで起こるうれしい変化


1. ブログにトラックバックがつく


2. コメントがつく


3. エントリが他のブログなどで紹介される


4. はてブがつく


5. Twitterでフォローされる


6. アフィリエイトで収入が入る


7. 知り合いが増える


8. 読者(アクセス数)が増える


それぞれ、いい意味と悪い意味の出来事があったりもします。

コメントがつく、と言っても批判・中傷のものもあったりしますしね。

ここではあくまで、うれしい出来事、と言うことに限定したいので、全てプラスの意味で起こるネット上の変化としたいと思います。



自分の場合は・・・


上記の項目を自分のうれしい順に並び替えてみます。


1. エントリが他のブログなどで紹介される


もちろんコメントだけもらっても十分うれしいのですが、他のブログで紹介する際のその人のコストを考えると、そうまでして自分のエントリを紹介してくれたのか、と感激します。

あとは、その紹介を通してさらに多くの人の目に留まるきっかけを与えてくれていることに感謝の気持ちがいっぱいになりますね。


2. コメントがつく


これは、ブログだけでなくTwitterでreplyなんかも当てはまることなんですが、やっぱり自分のエントリや発言に反応を示してくれることはうれしいことです。


3. 知り合いが増える


リアルに付き合う人、と言うことじゃなく例えハンドルネームしかわからなくても、ブログなどを通して気軽に会話を交わすことができる人が増えるのはうれしいことです。

そこから真に付き合いができる人が誕生したら最高ですけどね。


4. はてブがつく


別にはてブ限定と言うわけでないのですが、私のブログなんかは、まだまだ小さくてなかなか読者がいないので、その中で起こる変化というのは、活動するモチベーションにつながります。

わざわざブックマークすると言う行為をしてまで、そのエントリを取り上げてもらったことに、何らかの興味や役に立つものとして、その人に認知されたということにうれしさを感じます。


5. 読者(アクセス数)が増える


この辺は、その他の要因(他のサイトで紹介される)からそうなることが多いですが、地道に活動していて少しずつ読んでくれる人が増えると言う結果を見れば、ブログを書いていくモチベーションにつながります。


6. Twitterでフォローされる


これは、自分と言う個に興味を持ってくれたということとしてうれしさを感じます。

ブログで発信する情報は、自分の考えをある程度まとめたもので、それも自分の一つなんですが、どちらかと言うとその完成系の考えに興味を持つ、という方が多いような感じも受けます。

その個人に興味をもつと言うより、その考えに興味を持つというか。

Twitterの場と言うのはブログよりも、より個の内面が出る場所だと感じますので、自分と言う人に興味が出てフォローされたのであれば、やっぱりうれしいものです。


7. アフィリエイトで収入が入る


やっぱり収入が入ることはうれしいものですよ。えぇ。

まぁ、そっちをメインには考えられないので、あくまでご褒美程度のものだったりしますが。


8. ブログにトラックバックがつく


若干、トラックバックの意味が失われつつあるので、一番最後にしました。

トラックバックがついてもSPAM系のものが多いですしね・・・。

やっぱり、ちゃんと紹介されるよりはうれしさは劣ってしまいます。



反対にうれしくないものとしては、disられたり炎上されたりしたら、そりゃあもう・・・。

でも、地道に活動してたら、ネットでは何らかの変化が起きて、その変化が次への変化を起きるまでの原動力になります。

そんな変化が起きることを毎日楽しみにして、私は続けてたりしていますがね。


みなさんの考えはいかがでしょうか?




多くのLinux/Unix系サーバーではSSHでリモートログインしサーバー管理をするというパターンになっているかと思いますが、その際のSSHはパスワード認証が用いられていることが多いと思います。

これはもっとも手軽な認証方ですが、パスワードの総当り攻撃なんかを受けて看破される可能性があります。

そこでよりセキュリティをより高めるため、SSHでの公開鍵認証の設定を行ってみました。



SSHの公開鍵認証って?


公開鍵認証方式(公開鍵暗号を用いた認証方式)というのは、公開鍵(暗号するための鍵)と秘密鍵(複合するための鍵)の2つの鍵を用いて認証を行う方法です。

公開鍵は広く一般に知られて良いもので、その鍵を使ってデータを暗号化します。

暗号化されたデータは、その公開鍵とペアで作った秘密鍵でしか複合できません。


なので、秘匿性の高いデータをやり取りしたい場合、まずデータを受け取りたい側(クライアント)の公開鍵を使って、データを送信する側(サーバー)がそのデータを暗号化し、クライアントに送信します。
そして、クライアントは送られてきた暗号化データを自分の秘密鍵を使って複合して読み取るわけです。

たとえその暗号化された秘匿データが他人に渡って、秘密鍵を知りえない限り複合できません。(厳密に言えば複合できる可能性が極めて低い)

秘密鍵が複合鍵となっている特性上、必ず受信側の公開鍵を使うことになります。


SSHで公開鍵認証を行う場合、クライアント側で公開鍵と秘密鍵を作成し、公開鍵をSSHで接続するサーバー側に渡しておきます。

クライアントからSSHの接続要求をすると、サーバー側はクライアントの公開鍵を使って、暗号化したデータを送ります。

クライアントは、その送られてきた暗号化データを自分の秘密鍵を使って複合化し、サーバー側に送りなおし、サーバー側では送ったデータとクライアントから返されたデータが一致するかで認証を行います。

サーバー側から暗号化した質問の答えを正確に答えられるということは、その公開鍵とペアの秘密鍵を持っているから安全なやつだ、という判断で認証しているわけですね。



サーバー側の公開鍵認証設定


※ 公開鍵暗号の方式は、RSAとDSAがありますが、ここではRSAをベースに書いています。


まず、サーバー側で公開鍵認証が行えるようになっているかを確認します。
確認するのは、下記の3つのオプションです。


RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

上記が設定されているか(デフォルトでもyesなのでコメントアウトされててもOK)を確認します。

設定を変更した場合は、sshdデーモンを再起動しておきます。



Windowsクライアント(TeraTerm)を使った鍵作成と認証


次に、クライアント側の設定で、公開鍵と秘密鍵を作ります。

TeraTermには公開鍵・秘密鍵の作成機能があるため、その機能を使えば簡単に鍵の作成が行えます。

TeraTermを起動した後に[設定] → [SSHキー生成]メニューを開きます。


A Day In The Boy’s Life-TeraTerm鍵作成


キーの種類がRSAになっていることを確認し、「生成」ボタンを押します。

次に「キーのパスフレーズ」「パスフレーズの確認」欄に適当なパスフレーズを入力し「公開鍵の保存」「秘密鍵の保存」ボタンを1度ずつ押し、鍵を保存します。

秘密鍵は失うと認証できなくなりますし、盗まれると他のホストからログインされてしまう可能性がありますので安全な場所に保管しておきます。


※ パスフレーズを忘れると秘密鍵が読めなくなりますので注意しましょう。


これで鍵ができましたので、次に公開鍵(id_rsa.pub)をサーバーに保存します。

ログインするユーザーのホームディレクトリに.sshというディレクトリがあるかと思うので(ない場合は一度SSH接続すれば作成されます)、そのディレクトリ以下にそのまま保存します。

保存した後は、権限を700に変更しておきます。


$ chmod 700 id_rsa.pub

次に保存した公開鍵をauthorized_keysファイルへも追記しておきます。

authorized_keysファイルは、サーバー側のSSHの設定ファイルのAuthorizedKeysFileオプションのパスに保存し、権限を644に変更します。(デフォルトだと同じ.sshディレクトリ)


$ cat id_rsa.pub >> authorized_keys
$ chmod 644 authorized_keys

※ それぞれのファイルは、接続するユーザーの所有者・グループになっている必要があります。


もし複数の公開鍵を登録したい場合は、同じファイルに鍵情報を追記していきます。

これで、設定が完了したので、クライアントから接続してみましょう。


TeraTermを立ち上げ、公開鍵を設定したサーバーを指定します。

.sshディレクトリにに公開鍵を設定したユーザー名と鍵を生成した際のパスフレーズを入力し、「RSA/DSA鍵を使う」をチェックし、保存した秘密鍵を指定します。


A Day In The Boy’s Life-TeraTerm接続


そして接続を押せば、公開鍵認証方式でログインできます。


実際にサーバー側のログ(/var/log/secure)を見てみると


May 14 21:59:36 localhost sshd[2185]: Accepted publickey for hoge from 192.168.0.100 port 2034 ssh2
May 14 21:59:36 localhost sshd[2185]: pam_unix(sshd:session): session opened for user hoge by (uid=0)

というようにpublickey(公開鍵認証)でログインしている情報があるかと思います。



Linuxクライアントを使った鍵作成と認証


次は、Linuxクライアントから認証を行ってみます。

基本的には同じような設定をすることになるのですが、鍵の作成やコマンドラインからの接続方法などはWindowsと異なりますので。


まず、鍵の作成からですが、これはssh-keygenコマンドを使って作成します。


$ ssh-keygen -t rsa -C "hoge@192.168.0.100"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Your identification has been saved in /home/hoge/.ssh/id_rsa.
Your public key has been saved in /home/hoge/.ssh/id_rsa.pub.
The key fingerprint is:
65:ad:a7:e0:85:5a:b5:85:9e:0d:5b:61:bc:ca:25:cc hoge@192.168.0.100

鍵を作成するユーザーと実際に接続するユーザーが同一であれば、最後の「-C」オプションは必要ありませんが、異なる場合は接続するユーザー名とIP(またはホスト名)を指定して実行します。

途中キーの保存場所とパスフレーズが聞かれるので適切なものを指定しておきます。

鍵の作成場所は最後に表示される(上記の場合は、/home/hoge/.ssh/)ので、より適当な場所があれば移動させて安全に管理するようにしましょう。


これより先のサーバー側への公開鍵の設定は、先ほどのWindowsの場合と同様です。

公開鍵(id_rsa.pub)をサーバー側のログインするユーザー(鍵を作成したユーザー、または鍵を作成する際にコメントに入れたユーザー)の.sshディレクトリ以下に保存しておきます。


これで設定が完了したので、実際に接続してみます。


$ ssh -l hoge -i .ssh/id_rsa 192.168.0.100
Enter passphrase for key '.ssh/id_rsa':

「-i」オプションを付け、秘密鍵のパスを指定します。

実行後は、パスフレーズが求められるので鍵を作成した際に指定したものを入力します。



SSHのセキュリティの考察


ここからは若干雑談ベースで。

サーバーがSSHのどういった認証方式が利用可能なのかは、デバッグモードのオプションをつけて実行してみるとわかったりします。


$ ssh -v hogehost
- snip -
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/hoge/.ssh/identity
debug1: Offering public key: /home/hoge/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /home/hoge/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:

多くの情報が出てきますが、その中の「Authentications that can continue:」という行に、このサーバーで認証可能な方式が表示されます。

publickeyは公開鍵認証方式、passwordはパスワード認証、keyboard-interactiveはチャレンジ・レスポンス認証が許可されているということがわかります。


なので、パスワードの総当り攻撃とかは、そのサーバーがパスワード認証が許可されているかどうかが事前にわかるので効率的に行えたりすることもわかります。

じゃあ、そういうの受け付けなくするために、公開鍵認証だけ許可するようにするということもできます。


- パスワード認証とチャレンジ・レスポンス認証を許可しない設定

PasswordAuthentication no
ChallengeResponseAuthentication no

これで、実際に接続してみたら


$ ssh -v hogehost
- snip -
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/hoge/.ssh/identity
debug1: Offering public key: /home/hoge/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/hoge/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
debug1: Calling cleanup 0x8062d60(0x0)


というように、公開鍵がサーバー側に登録されていない限り、いきなり接続を拒否られたりします。


この状態だと秘密鍵を持つPCからだけしか接続できなくなり、安全だということになりますが、その秘密鍵をなくしたり、PCが飛んだりしたら接続の方法がなくなってしまいます。

パスワード認証は、個人を特定して認証する方式ですが、公開鍵認証はホストを特定して認証する方式になりますので、そのホストの管理が重要になってきます。


もちろん鍵をバックアップしておくということは必要ですが、秘匿性の高い鍵情報を分散させすぎると鍵が漏洩するリスクも高まってきます。

なので、このような鍵認証はあまり個人が管理するサーバーには向かない方式なのかと思います。

その個人がいなくなったり、鍵を紛失したらどうしようもなくなります。

複数人の管理者がいるなら、他の管理者に再登録してもらうことも可能ですが、1人だと代替案が何もなくなってしまうリスクがあるからです。


あとは、SSHの設定だけで考えるのではなく、N/Wによる制限(TCP Wrappers、iptablesとか)とか、以前に書いた「超制限付きユーザーの作り方 」のようにほとんど何もできないユーザーを作って、そいつをログイン専用ユーザーにするとか、そんな対策も重要になってくるかなと思います。





経験の浅い子と仕事をしていると何かと質問されることがあります。

もちろん仕事をしている上でわからないことがあったら、人に聞いて正しい答えやヒントをもらうと言うのはいいのですが、質問される内容にはそれって調べたらすぐ答え出るんじゃない?ってことが多くあったりします。


※ 逆に本当に新入社員の子は、遠慮してこっちが聞かないとなかなか状況を話したりしません。

  こういうのが多いのは環境に慣れてきた2年目以降の子ですかね。


特に技術的なことは多くはネット上にあったりしますし、自分自身も経験のないことは調べならがら試行錯誤するというタイプです。

というより、自分の頭にない、社内にドキュメントもない、周りに知識を持っている人もいない、と言う状況ではもう外に頼るしかないわけです。

別にネットだけでなくても参考書を読むとかでもいいでしょう。


私自身は、先輩のいない環境で仕事をしてきましたので、外から知識を持ってくるしかない状況でした。

同僚はいましたが、持ってる知識なんてどんぐりの背比べほどのものです。

新しい仕事をするときは、参考書を買ってくるかネットで調べるかしかありませんでした。

特別に何か検索テクニックを教わったわけではないですが、周りと試行錯誤しながら情報を集め、ただひたすらに試してみると言うことを繰り返すことをやっていました。

非効率ではありますが、自分でやりぬくための術は身についたかなと思っています。

逆にどんなに経験のないことでも調べれば出てくるだろ、と楽観的に見てたりもします。


何でも質問をする人は、すぐに答えを知りたい病になっている人が多いような気がします。

確かにネットで調べれば何らかの答えはすぐに返ってきますが、それ以上に効率を求めるなら知っている人に聞くのが最も手っ取り早い選択です。

適当なキーワードを選んで出てきた検索結果のページからそれが辺りかどうかを判別していく作業がありますので、的確なキーワードで検索してもその判別作業に時間が取られます。

また、それを自分の環境に置き換えるなんかの応用にも時間が取られます。


が、その辺のことを聞かれて答えを教えるぐらいなら自分がやってしまった方が早いわけです。

仕事を分担することは時間を分担することでもあります。

あるタスクをこなすのに割く時間を分割したのに質問して答えを教える時間を取られることで、質問した人の時間は削減できるけど、質問されるた人の時間は増えてしまいます。


もちろん何にも質問するなと言うことではありません。

答えが外にない場合もありますし、仕事を割り振った人の意図が不明な場合もあるでしょう。

ただ、その切り分けをして、さらに自分の持ってる能力で情報を探しきれなくなったと言う結果、どうにもできない状況が作られて質問をするべきじゃないかなと。

先ほど言ったようにこれは、当人にとってはものすごく非効率なことですが、そうでもしないと仕事を割り振っている意味が出てきません。


そういうことで、その自己解決能力を磨く意味でも新人研修で検索能力を鍛えるプログラムでも取り入れたらどうでしょうかね、と思ったりしました。

特定の検索エンジンに絞った研修でもいいかもしれません。

Googleなんかは検索オプションがいっぱいありますから、その知識を持っていることでより精度の高い検索ができるようになると思いますし。


エンジニアにはエンジニアの検索方法を、営業には営業の検索方法ってもんがあると思います。

それは、実際に何も知らない状況だと何をどう検索していいかもわからなかったりします。

検索ワードって意外とイマジネーションが必要になったりするものです。

それを研修とかで教えておくことで、仕事の効率も上がると思うんですが如何でしょうか。