実際に設定してみよう!

05.08.10 / SSHって何? / Author: / Comments: (2)

まず秘密鍵と公開鍵をつくりましょう!

$ ssh-keygen -t rsa

すると、このように言われます。

Generating public/private rsa key pair.

Enter file in which to save the key (/home/usako/.ssh/id_rsa):

鍵の保存場所を聞かれているので、そのままENTERを押します。

つぎに、パスフレーズをつくります。

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

パスフレーズは秘密鍵を使うためのパスワードのようなものでしたよね。

公開鍵方式では復号化のためには秘密鍵を持っていること&パスフレーズを知っていることを必要とします。

Your identification has been saved in /home/usako/.ssh/id_rsa.

Your public key has been saved in /home/usako/.ssh/id_rsa.pub.

The key fingerprint is:

c3:09:db:b2:6f:f2:c7:52:e7:65:ca:c6:39:d4:a0:8d usako@usako-usagi.local

このようにでれば、公開鍵と秘密鍵の作成はクリアです!

本当にできているのか確認しましょう。

$ ls -la ~/.sshと入力して、

-rw——-   1 usako  usagi  1743  8  4 14:38 id_rsa

-rw-r–r–   1 usako  usagi  405  8  4 14:38 id_rsa.pub

と出ればOKです!

サーバーに入る前に、つくった公開鍵をサーバーにコピーしましょう。

$ scp id-rsa.pub [サーバー名] : /home/usako/

つぎに、ssh [サーバー名]とパスワード認証でサーバー内に入り、つくった公開鍵をサーバ側に登録しましょう!

公開鍵はサーバ側の~/.ssh/authorized_keysファイルへ登録します。

~/.ssh/authorized_keysは、ユーザーの公開鍵を登録するための設定ファイルです。

まず、サーバー側のホームディレクトリに.sshディレクトリをつくります。

$ mkdir ~/.ssh

$ ls -laをすると、.sshができていることがわかります。

drwxr-xr-x   2 usako wheel  4096 Aug  5 12:20 .ssh

こんな風にでます。

つぎに.sshのパーミッションを変更します。

.sshのパーミッションをユーザーのみ読み書き実行できるにしたいので、

$ chmod 700 ~./sshと入力します。

$ cd .sshで.sshに入り、コピーしておいた公開鍵id_rsa.pubを ~/.ssh/authorized_keysに登録します。

$ cat ../ id_rsa.pubとすると、公開鍵のファイルの中身が見ることができます。

これを~/.ssh/authorized_keysに登録します。

$ cat ../id_rsa.pub >> authorized_keys

そのあと、$ cat authorized_keys と入力すると、$ cat ../id_rsa.pubと同じものがでるはずです。

authorized_keysのパーミッションも変更しましょう!

こんどはユーザーのみ読み書きOKとします。

$ chmod 600 authorized_keys

これでサーバー側に公開鍵が登録できました!

次はユーザー認証の方法をパスワード認証から公開鍵暗号方式に変更します!と言いましょう!

$ cd /etc/ssh/で設定ファイルのある/etc/sshに移動します。

sshdの設定ファイルはsshd_configです。なのでこのファイルを編集しましょう。

$ vi sshd_config

#PubkeyAuthentication yesをPubkeyAuthentication yesに変更(#を削除)

#PasswordAuthentication yesをPasswordAuthentication noに変更(#を削除してyesをnoに)

再起動しましょう!

$ /etc/init.d/sshd restart

Stopping sshd:                                             [  OK  ]

Starting sshd:                                             [  OK  ]

とでればOKです!

もうひとつターミナルをひらいて$ ssh [サーバー名]でサーバーに入ってみましょう!

パスフレーズを聞かれたら設定できている証拠です!

$ ssh-keygen -t rsaで鍵作成

Enter file in which to save the key (/home/usako/.ssh/id_rsa):はそのままenterを押す

Enter passphrase (empty for no passphrase):パスフレーズ入力

Enter same passphrase again:もう一度入力

$ ls -la ~/.sshで鍵ができているか確認

$ scp id-rsa.pub [サーバー名] : /home/usako/でサーバーに公開鍵をコピーする

ここまでで鍵作成完了

ssh [サーバー名]とパスワード認証でサーバー内に入る。

$ mkdir ~/.sshで.sshディレクトリを作成

$ chmod 700 ~./sshで.sshのパーミッションを変更

$ cd .sshで.sshディレクトリに入る

$ cat ../id_rsa.pub >> authorized_keysで公開鍵をauthorized_keysファイルに登録する。

$ chmod 600 authorized_keysでauthorized_keysのパーミッション変更

ここまででサーバー側に公開鍵を登録完了

$ cd /etc/ssh/で/etc/ssh/に移動

$ vi sshd_configでsshdの設定ファイルを編集

#PubkeyAuthentication yesをPubkeyAuthentication yesに変更(#を削除)

#PasswordAuthentication yesをPasswordAuthentication noに変更(yesをnoに)

PasswordAuthentication yesを削除

ここまでで、ユーザー認証の方法をパスワード認証から公開鍵認証に変更

$ /etc/init.d/sshd restartで再起動

もうひとつターミナルを開いて$ ssh [サーバー名]でパスフレーズを聞かれたらOK

公開鍵暗号方式によるユーザー認証のしくみ

05.08.10 / SSHって何? / Author: / Comments: (1)

KEY認証でも同じようにホスト認証が行われますが、パスワードではなく、鍵を使ってユーザー認証を行います。

最初にクライアントはつくった公開鍵をホストのファイルに登録しておく必要があります。

次に、$ ssh [サーバー名]と入れてホストに通信要求すると、ホスト認証が始まります。

ホスト認証によって正しいホストであると認証されると、ユーザー認証が始まります。

サーバはランダムな値をつくり、authorized.keysに登録してあるクライアントの公開鍵によって暗号化してクライアントに送ります。

↓パスフレーズってこんなかんじ?らしい↓

ホストから暗号を受け取ったクライアントは自分の秘密鍵でその暗号を復号化をします。

しかし、この秘密鍵を使うためにはパスフレーズが必要です。。

パスフレーズは秘密鍵を使うために必要なパスワードのようなものです。

パスフレーズを正しく入力できないと、そのクライアントは正しい秘密鍵の持ち主ではないとされてしまいます。

正しくパスフレーズを入力できたら、クライアントはその秘密鍵でホストから送られてきた暗号を復号化して、その結果をホスト認証の時つくった共通鍵で暗号化して送ります。

サーバは返送されたデータと暗号化前のデータを比較して正しければ本物のクライアントであると認証します。

ホスト認証のしくみ

05.08.10 / SSHって何? / Author: / Comments: (0)

前回、通信要求をしてきたIPアドレスは登録されているものなのかを確認することでアクセス制限を行いましたが、今回は、鍵を持っているのか?を確認することによるアクセス制限、KEY認証を勉強しました。

KEY認証が適用されていない状態で通信要求をすると、ホスト認証とパスワード入力が行われます。

この時、公開鍵暗号が使われ、ホストはクライアントに公開鍵を送信します。

初めて通信要求を行った時

Are you sure you want to continue connecting (yes/no)? と聞かれ、yesと答えます。

これは、送られてきた公開鍵を登録するかを聞かれているのです。

また、すでに登録されている場合は、データとの照合が行われます。

クライアントは通信に使う共通鍵を作成し、ホストから送られてきた公開鍵で暗号化してホストに送信します。

ホストは受け取ったデータを秘密鍵で復号化して共通鍵を得ます。

復号化をできる=秘密鍵を持っている=本物と認められます。

その後、クライアントはユーザーは本物なのか?とパスワードを尋ねられ、クライアントは共通鍵で暗号化したパスワードをホストに送ります。

しかし、公開鍵は誰でも得ることができるため、ログイン画面までは誰でも行くことができます。

そのため、この方法だと前々回勉強したようなアタックの危険があります。

そこで登場するのがKEY認証です!

共通鍵方式と公開鍵方式

05.08.10 / SSHって何? / Author: / Comments: (1)

今日は小悪魔ブログ怒濤の更新です!

SSHでは、共通鍵方式と公開鍵方式のふたつのKEY認証の方式があり、それぞれの弱点を補いながら通信データの暗号化をしています。

共通鍵方式は、クライアントとサーバがお互い同じ鍵を使用して暗号化と復号化を行います。

共通鍵方式では、お互いに同じ共通鍵を持っていなければ解読することはできません。

また、共通鍵はCPUパワーをあまり使わずに強い暗号強度を得ることができます。

しかし、共通鍵方式は、1つの鍵で暗号化と復号化を行うため、ネットワークにそのまま流してしまうと、鍵が第3者にわたって通信データを盗聴されてしまう危険があります。

公開鍵方式は、暗号化をする公開鍵と復号化をする秘密鍵の2つの鍵を使います。

暗号化に使う公開鍵はネットワークに流しますが、復号化を行う秘密鍵を流すことはないのでかなり安全に通信を行うことができます。

しかし、公開鍵方式は、効率が悪く、CPUパワーをたくさん使ってしまいます。

そこで、SSHでは、共通鍵を渡す時にのみ公開鍵方式をつかって暗号化・復号化を行い、共通鍵を渡した後は共通鍵を使って通信を行うようになりました。

また、共通鍵を送受信のセッション毎に使い捨てで使用することで、通信データはより強固なものとなりました。

IP制限をしてみよう!

02.08.10 / SSHって何? / Author: / Comments: (7)

前回見たアタックを回避するための方法の1つとして、IPアドレスの制限というものがあります。

SSHのIP制限では、/etc/hosts.allowと/etc/hosts.denyの2つのファイルに設定することで、特定のIPを拒否したり、自分以外のIPすべてを拒否したりします。

今回は、私が利用しているIPアドレス以外のIPアドレスを拒否する設定をしました。

$ ssh [サーバー名]でサーバに入り

パスワードを入力

$ suでroot権限に

# vi /etc/hosts.denyで/etc/hosts.denyの編集

iで編集モードにしてsshd : ALLと一番下に書き、

escで編集を終わらせ、:wqで保存して終了。

この状態にするとすべてのIPアドレスが拒否されます。

ターミナルをもう一つ開いて

$ ssh [サーバー名]と入れてもログインできなければ設定ができています。

次に/etc/hosts.allowの設定をしましょう。

# vi /etc/hosts.allow で/etc/hosts.allowの編集

iで編集モードにしてsshd : [許可するIPアドレス(ここでは自分の)]と書き、escで編集を終わらせて :wqで保存して終了します。

すると今度は自分のIPアドレス(許可されたIPアドレス)でのみ入ることができます。

/etc/hosts.denyで設定されていても、 /etc/hosts.allowで許可されていれば、そのIPアドレスから入ることが可能です。

もうひとつ開いていたターミナルで

$ ssh [サーバー名]と入れパスワードを入れてログインできたので設定できています。

$ ssh [サーバー名]

パスワード入力

$ su

パスワード入力

# vi /etc/hosts.deny

sshd : ALL

# vi /etc/hosts.allow

sshd : [許可するIPアドレス]

今回 /etc/hosts.denyと /etc/hosts.allowでIP制限の設定ができたのは、sshdがTCPwrapperのライブラリを利用しているからです。

もともとTCP Wrapperとは、スーパーサーバーinetdで利用されるアクセス制限のプログラムです

inetdとは、複数のサービスを監視し、要望があればそのデーモンを起動するためのスーバーサーバーです。スーパーサーバーを使うといつでもクライアントの要求を受けるために複数のサーバを起動しつづけてCPUやメモリの消費を抑えることができます。

また、TCP Wrapperとinetd(+α)の機能をもったxinetdが最近では使われています。

しかし、スーパーサーバを経由すると通信速度は遅くなるため、httpなどよく使われているデーモンではスーパーサーバーを経由することはありません。

今回、/etc/hosts.denyや/etc/hosts.allowを編集することでsshでIP制限ができたのは、/etc/hosts.denyと/etc/hosts.allowがTCP Wrapperの設定ファイルで、sshがTCP Wrapperのライブラリを使用しているからなのです。

TCP Wrapperは、スーパーサーバーであるinetdでのみ使用されていたプログラムですが、SSHでもTCP Wrapperライブラリを利用することによってアクセス制限ができるようになっているのです。

ログからアタックのすごさを見てみよー!

30.07.10 / SSHって何? / Author: / Comments: (7)

今日は、アクセス制限に入る前に、ログからアタックのすごさを見てみることにしました。

アタックとは、悪意をもって他のコンピュータのデータやプログラムを盗み見ようとしたり、改ざんしようとしたりする攻撃のことです。

今回は会社の方にログを頂いてアタックのすごさを見てみました!

Mar 29 12:22:21 ecosign sshd[32760]: Invalid user matsuno from 209.9.188.68
Mar 29 12:22:25 ecosign sshd[32766]: Invalid user tokutake from 209.9.188.68
Mar 29 12:22:28 ecosign sshd[1333]: Invalid user yamaguci from 209.9.188.68
Mar 29 12:22:31 ecosign sshd[1339]: Invalid user okawara from 209.9.188.68
Mar 29 12:22:35 ecosign sshd[1345]: Invalid user sakuma from 209.9.188.68
Mar 29 12:22:38 ecosign sshd[1352]: Invalid user iwa from 209.9.188.68
Mar 29 12:22:42 ecosign sshd[1358]: Invalid user jackie from 209.9.188.68

これはそのほんの一部です。

秒単位でアタックがきています。

前回、「暗号化されていないとAとBの間にわるうさぎさんが入り込めれば(簡単には入り込めないですけどね。)…」と書きましたが、わるうささんはこんなかんじで悪いことをしようとがんばってたりします。

このログを見ると、userの右隣がアタックしている人が試しているアカウント名です。yamaguci、sakumaなど、ユーザー名をよくある名字や名前を入れてコンピュータに侵入しようとしているのがわかります。一番したのjackieなんて面白いですね:)

このように秒単位で何度も何度も違うユーザー名を考えながらアタックを繰り返すのはとても大変ですが、万が一そのアタックが成功してしまってはこちらも困ってしまうわけです。

そのため、アタックによって危険がおよばないようにするためにアクセス制限というものがあります!

つづきます!

暗号化はそんなに必要なのかな?

29.07.10 / SSHって何? / Author: / Comments: (1)

前回のおさらいです*

それでは今回のお題は…

このツールを使えば、SSHで暗号化されていない情報がもしかしたら見れてしまう(盗聴できる)かも?

ということで、今回は生データの危険性をtsharkを使って検証してみました!

今回はIPアドレス○○○.○○○.○○○.○○○(以下Aとします)から●●●.●●●.●●●.●●●(以下Bとします)にsshやtelnetをし、検証しました。

ターミナルを2つひらき、

片方にはssh [アカウント名]@[AのIPアドレス]と入れAにログインします。

もう片方にはssh [アカウント名]@[BのIPアドレス]と入れ、Bにログインします。

今回は、AからBにsshやtelnetをする(AからBにログインする)ので、

Bのターミナルに、パケット内容を表示させるために

tshark -x -i eth1 host [AのIPアドレス] and port 23と入力しておきます。

Aの方のターミナルには、

telnet [BのIPアドレス]と入力します。

すると、

Trying [BのIPアドレス]…とでるので、

login :に、アカウント名、password :にパスワードを入力します。

すると、Bの方のターミナルに、Aのターミナルからtelnetで送られているパケットが表示されます。

たとえば、Aのターミナルに ls -laと入力すると、Bのターミナルでls -laで見られる内容がB -> A TELNET Telnet Data …のなかで見れてしまったりします。

ls -laを入力するとAのターミナルにこのようにでました。下から2番目にusakumaとあるのがわかります。

するとBのターミナルにはこのように表示されます。真ん中の数字が16進数、右がASCLLダンプです。

ASCLLダンプの下から5、6行にかけてusakumaと表示されちゃってますよね。他にもls -laでAにでてきた文字が見れてしまっています。

こんなかんじでパスワードなどの大事な情報もそのままの状態で流れてしまったり…。

今度はBのターミナルに、

shark -x -i eth1  host  [AのIPアドレス] and port 22と入力します。

さっきはport 23でしたが、今度はport 22です。これはSSHのポート番号です。

Aの方のターミナルには、

ssh [AのIPアドレス]と入力します。

すると、今度はBのターミナルには、Aのターミナルからsshで送られているパケットは何がかいてあるかわからない状態で表示されます。

ほとんど…になっていて読めなくなっています。

これは、SSHが通信を暗号化しているからです。

本当は上のイラストでわるうさぎさんが盗聴をしているような、通信をするAとBの間で盗聴は行われます。今回は環境がなかったのでBの場所で行いました。

暗号化されていないとAとBの間にわるうさぎさんが入り込めれば(簡単には入り込めないですけどね。)盗聴できてしまいます。

AとBへのログイン権限を持っていなくてもモニタリングできてしまうことはとても問題です。

SSHってなんだろう2

28.07.10 / SSHって何? / Author: / Comments: (10)

前回、SSHでは、ユーザーがローカルホストに入力したコマンドをsshクライアントがうけ、ネットワークをとおしてsshサーバへ送り、リモートホストであるサーバコンピュータにコマンドを実行させているということがわかりました。

しかし、この間にはさむネットワークはとても危険な空間です。

システム管理作業では、時に管理者のパスワードや、セキュリティ設定情報をやりとりします。もしインターネットを通じてシステム管理をすると、こういった機密度の高い情報がそのままの形でインターネットを流れてゆくことになります。途中で誰かが盗み見たり(盗聴)、通信内容を偽造(改ざん)する可能性はゼロではありません。

SSHと似たしくみを持ったものに、telnetやrloginなどがありますが、パスワードをそのままネットワークに流してしまうなど、セキュリティに問題点が多くあります

そこで、SSHで行われるのは通信経路全体の暗号化です。

SSHでは、SSHクライアントとSSHサーバの間での通信を暗号化しています。

そのため、もし途中で誰かが盗み見ようとしても、通信内容を知ることはとてもむずかしく、危険なネットワークを安全に通すことができるのです。

SSHってなんだろう?

28.07.10 / SSHって何? / Author: / Comments: (3)

DNSはしばらくお休みして今日はSSHについて勉強しました!

このブログでも何回かでてきている「SSH」

よくわからないまま書いてるけどsshって何だろう?

…ということで今日はsshについてのお勉強です*

SSHとはSecure SHell (セキュア シェル)の略です。

小悪魔ブログ内のSSHの文字を探すと、sshでサーバーに入り設定ファイルを編集しています。

sshとはサーバコンピュータが目的どおり動くよう設定を編集、プログラムの開始や停止をするために、サーバコンピュータの中に入るための、サーバ管理の必須ツールなのです!

小悪魔ブログ内のSSHの文字を探すと、sshコマンドでサーバに入って、コマンドによってファイルを作成したり編集したり削除したり…コマンドを理解できなくてブログの記事がかけなくてよくこんな状態になってました。

例えば、ファイルの削除なんてファイルのアイコンをゴミ箱に入れたら終わりジャン!コマンドなんて必要ないジャン!って思うけれど、そのコンピュータから離れた場所から管理作業をするとしましょう。

マウスとアイコンを使った方法(GUI)では、デスクトップ画面すべての情報を送らないといけません。しかし文字だけで管理する方法(CUI)なら、やりとりするのは文字情報だけ送れば十分です。文字で管理する方法の方が、送るべきデータの量が圧倒的に少なくて済むのです。

SSHを使えばネットワークを介して、離れた場所のサーバコンピュータにログインすることができるので、離れた場所からCUIでコマンドを実行することができるのです。

ユーザーがローカルホストに入力したコマンドをsshクライアントがうけ、ネットワークをとおしてsshサーバへ送り、リモートホストであるサーバコンピュータにコマンドを実行させます。

つづきます!