2017年06月28日

git ブランチについて

git については、ここや、ここで触れた。
今回は、git に不可欠なブランチについてさらっと触れてみたい。

git の origin とは


ブランチの話の前に、"origin" について。
これは、リモートブランチのサーバ名のこと。

以下のようにすると、"origin" がどこを指しているかわかる。

$ git config --list

remote.origin.url=gitserver:~/git/project1.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*







git の ブランチ とは


git で管理する作業履歴を示すもの。コミットしていくと履歴が増えるが、その履歴を繋いでいく構造がブランチ。
git_branch01.png



木の枝のように、枝分かれさせ管理することが可能。
git_branch02.png



初期のブランチの状態を見てみる。

$ git branch

* master

"master" とある。これがデフォルトのブランチ。最初にコミットすると作成される。

"origin/master" と表現された場合は、リモートリポジトリ(origin)の "master" ブランチを示している。


ちなみに、デフォルトで "master"ブランチは存在するが、必ずしもブランチ名称を"master"とする必要はない。
例えば、project1開発で git を運用したとして、"master"の名称を変えて見る。

$ git branch -m master project1

$ git branch
* project1

"master" ではなく、"project1" ブランチになった。これで運用しても良い。






新しいブランチをつくる


ひとつのブランチから、枝分かれさせ、新しいブランチを作る。
これを「ブランチを切る」ともいう。

新しいブランチ "new_branch" という名称で作ってみる。

$ git branch new_branch

$ git branch
* master
new_branch

新しく "new_branch" が存在した。
"*"(アスタリスク) がついているブランチが現在の作業ツリーの状態を示している。
上記では "master" ブランチで作業している状態だとわかる。


ここでファイルを変更してcommitすると、"master"ブランチの履歴に追加される。
一方の"new_branch"は影響しない。



"new_branch"で作業を行うためには、作業ツリーを切り替える。
この操作を チェックアウトと言う。

$ git checkout new_branch

Switched to branch 'new_branch'


$ git branch
master
* new_branch


ここでファイルを変更してcommitすると、今度は、"new_branch"ブランチの履歴に追加され、一方の"master"は影響しない。
git_branch03.png



"$ git branch" で示される、"*"(アスタリスク)は、現在チェックアウトされているブランチとも言える。



ここでブランチのイメージを修正しておこう。
「ブランチ」という名称なので、木の幹・枝のイメージで記述したのだが、コミットというのは、直近のコミット(親コミット)へのポインタが格納され、それをつなげていくことで変更履歴が構築される。下図のように矢印は直近のコミットを指す向きほうが正しく表現している。そして「ブランチ」は最新のコミットを指すポインタのことなので、「ブランチ」というのはコミット位置に当てるのが良いだろう。
git_branch04.png
図で書くとこうなるのだが、変更履歴の表現として心情的に「古い」→「新しい」へと向かわせたいので、以降も矢印の向きは古いコミットから新しいコミットへつなげていくことにする。




それから「ブランチを切る」というのは、最新のコミットを指すポインタを新しく作ることなので、ブランチを切った直後はこのようになる。
git_branch05.png
その後、コミットするとブランチ(ポインタ)が最新コミットを指すように自動的に更新される。
git_branch06.png


話を少し戻して、チェックアウトの状態の管理はどうなっているのか?
これは "HEAD" というポインタで示される。
"master" ブランチをチェックアウトしたのであれば、"HEAD" は、"master" を指すポインタになっている。
git_branch07.png






ブランチのマージ


ブランチを切る理由はいろいろある。
機能を追加する際に、機能がきちんと動作するまで分離するとか、不具合修正が完了するまで分離するとか。
こういう理由でブランチを切って分岐させたのであれば、それは一時的な分岐であり、いつかは本流に戻してあげないと本来の目的に達しない。
git のブランチ管理には、ブランチを切った先での変更を共有することができる。
この操作には、"merge" コマンドを使う。この操作は変更を共有する側で作業をする。

ただし、ブランチした後、分岐元にcommitがあるか・ないかでマージ動きが変わる。

分岐元で変更がなかった場合


git_branch08.png
"new_branch" ブランチを "master" ブランチにマージする。
この場合、単純に "master"ブランチ(= ポインタ)を挿げ替えるだけ。
"master" ブランチをチェックアウトし実行する。

$ git merge new_branch

Updating 76eb1f6..693e085
Fast-forward
index.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

"master" ブランチは、"new_branch" ブランチと同じコミットを示すようになった。
git_branch09.png
これを "fast-forward" マージという。



分岐元で変更があった場合


git_branch10.png
"new_branch" ブランチを "master" ブランチにマージする。コマンドは "fast-forward" マージと同じ。
"master" ブランチをチェックアウトし実行する。

$ git merge new_branch


コミットログをグラフ表示にして確認する。
$ git log --graph
* commit 674649a321b87801de0afea9389a162a66cac60d
|\ Merge: d7af236 5230eda
| | Author: hoge hogehoge
| | Date: San Jun 25 20:00:00 2017 +0900
| |
| | Merge branch 'new_branch'
| |
| | Merge new_branch -> master
| |
| * commit 5230eda9e7070b084e250852ec1f29bcc65e0870
| | Author: hoge hogehoge
| | Date: San Jun 25 19:00:00 2017 +0900
| |
| | new_branch 追加2
| |
| * commit 71950fae9396a54bbf255b8466f3f15e93e76051
| | Author: hoge hogehoge
| | Date: San Jun 25 18:00:00 2017 +0900
| |
| | new_branch 追加1
| |
* | commit d7af236ea4c844862eaafb38fbd99e951a34dda3
| | Author: hoge hogehoge
| | Date: San Jun 25 18:30:00 2017 +0900
| |
| | master branch 追加2
| |
* | commit 8673bdfb53790b7dc42a8a9ecf24491641c868f9
|/ Author: hoge hogehoge
| Date: San Jun 25 11:00:00 2017 +0900
|
| master branch 追加1
|
* commit 76eb1f66a10cea1ac9e3b3b1f59b5fe946a29467
| Author: hoge2
| Date: San Jun 25 10:10:00 2017 +0900
|
| master branch.
|
* commit b396e3f7adef3c4cedbda55df20ceac837750e0b
Author: hoge hogehoge
Date: Sat Jun 24 16:00:00 2017 +0900

Add new file.

ログを見ると、両方の変更履歴を取り込んだマージコミットが作成されている。
"master" ブランチは、このマージコミットを指している。
fast-forward マージでは、このマージが行われないためログ上にマージコミットが出てこない。
git_branch11.png


マージ操作については、こちらでより詳しく説明する。



まとめ


ブランチの統合についてはもっといろいろあり奥が深い。
今回は「ブランチとは」という点で触れたかったので、表面をさらっと流した。
何気なく使っていたので、以外にわかってなかった点もあったが、自分なりにもやもやしたところが晴れて、納得できた。


gitをインストール
gitサーバーのセットアップ
git 変更を一時的に退避 stash
git ブランチを合流するマージ
git ブランチを付け替える
git コミット履歴を変更する
git コミットを取り消す
git 変更をリセットする
git リモートでの操作
git リリース準備
git リモートブランチを追加
git チェックアウトをもっと便利に使う
git プロジェクトの構成
git 変更をpatchファイルにする
git コンフリクトに対処する
git 失敗したときの復元
posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年06月26日

Ubuntu メモリキャッシュクリア

現在のメモリの使用状況を確認してみる。

$ free -h

             total       used       free     shared    buffers     cached
Mem: 3.5G 756M 2.7G 1.1M 44M 479M
-/+ buffers/cache: 232M 3.3G
Swap: 3.6G 0B 3.6G




Linuxのメモリ使用についてよくわかっていなかったので調べてみた。

Linuxのページキャッシュについて


まずキャッシュとは、データへのアクセスを速くするために、より高速な記憶装置に一時的に保存する仕組み。
で、ページキャッシュとは、
  • CPUはストレージから直接読むことはできない
  • そのため、ストレージのデータを一旦メモリにロードしてから読み込む
  • Linuxは一度ストレージから読みだしたデータは可能な限りメモリにキャッシュし、次回以降の読み込みが高速に行われる
  • Linuxは、メモリ領域をページという単位(ページの大きさははCPUの種類で異なる)で管理する
  • メモリ上に読みだしたデータのキャッシュのことを「ページキャッシュ」と呼ぶ


(補足)
freeコマンドで見ると、cached で示されるページキャッシュと buffers で示されるバッファキャッシュが存在する。 ページキャッシュはファイルシステムに対するキャッシュであり、ファイル単位でアクセスするときに使用されるキャッシュ。 もうひとつのバッファキャッシュは、ブロックデバイスを直接アクセスするときに使用されるキャッシュになる。



ページキャッシュの簡単な流れとしては、
  1. データにアクセスする処理が発生
  2. それはページキャッシュ上に無い
    (キャッシュ上にデータがあれば、ストレージにアクセスせずキャッシュのデータを使う)
  3. メモリに空き領域がある
    (メモリ上に空きが無ければ、ストレージから読み出したデータをキャッシュするため、古いキャッシュを捨て、新しいキャッシュを構築する)
  4. ストレージから読み出し、新しいキャッシュを構築する



つまり、データにアクセスするということは、ページキャッシュを構築することになる。
Linuxは空いているメモリをページキャッシュに使おうとするので、時間とともにページキャッシュは増加していく。そして、ページキャッシュは新たなストレージへのアクセスがあっても、メモリが必要にならない限り解放しない。




利用可能なメモリ量


おおよその利用可能なメモリの量は、freeコマンドで表示される1行目(Mem: )のfreeの値ではなく、2行目(-/+ buffers/cache:)のfreeの値を確認する。
2行目のfreeは、1行目のfreeにbuffersとcachedを加えた値。

これは、上述の通り、バッファ(buffers)とキャッシュ(cached)が使用している値も結果的には空きメモリとして使用できるため。
1行目のfreeだけ見て、少ないと思うようなことがあっても、2行目を確認してみると問題ないことが多い。
ページキャッシュは必要が無ければメモリ解放しないが、一方で、ページキャッシュは使って無ければ、すぐに破棄することは可能。つまり破棄できない領域と破棄できる領域がある。
freeコマンドの2行目のfreeには、この破棄できない領域のキャッシュも含まれている。


破棄可能なキャッシュを確認してみる。vmstatコマンドを使う。

$ vmstat -a

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free inact active si so bi bo in cs us sy id wa st
0 0 0 3091364 101108 373116 0 0 86 101 83 150 3 0 95 2 0


"-a" オプションで、メモリキャッシュの アクティブ "active" (利用中のため開放できない領域)と、非アクティブ "inact" (最後に利用されてから一定時間が経過しているので廃棄できる領域)の内訳を確認できる。


利用可能なメモリ量を算出するなら、freeコマンドで確認したMem行のfreeと、vmstat -aコマンドで確認したinactが実際に利用可能なメモリ量になる。



メモリキャッシュのクリア


これまでの内容で、キャッシュは空きメモリの一部と見れるので、これらが増加したからといってメモリを圧迫している訳ではないので、無理やり解放させる必要は無い。キャッシュはアクセス高速化のためなので、むしろ有益です。
ただ、パフォーマンス測定の場合は素の状態で正しく計測したいので、クリアしたほうが良い。

キャッシュの解放をコマンドからできる(Linuxカーネル 2.6.16以降)。

$ echo 3 > sudo /proc/sys/vm/drop_caches

または

$ sudo sysctl -w vm.drop_caches=3



数字は解放したいメモリを示す。
1: ページキャッシュ解放
2: dentry、inode 解放
3: ページキャッシュ、dentry、inode 解放

ページキャッシュがまだストレージへ同期されていない分を Dirty cache という。
この操作では、Dirty cahce は解放の対象外となる。

解放する前に、syncコマンド使って、Dirty cache を書き出してから、
解放を行うことで、より効果的な開放が行える。

$ sync
$ echo 3 > sudo /proc/sys/vm/drop_caches


posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年06月24日

Ubuntu インストールしたらやること:Rubyをインストール

プログラム言語Rubyをインストールする。
Ubuntu標準で提供されているのは安定版のため、最新版を入れれるように、PPAリポジトリを追加してインストールする。Rubyにはバージョンごとの違いがあるので、切り替えて使えるように、"ruby-switch" を利用をする。


インストール


端末で実行する。
PPAリポジトリを追加。

$ sudo add-apt-repository ppa:brightbox/ruby-ng

$ sudo apt-get update


まず、"ruby-switch" をインストール

$ sudo apt-get install ruby-switch



後は、インストールしたいバージョンのRubyを指定。

$ sudo apt-get install ruby2.3

$ sudo apt-get install ruby2.4







インストールされているRubyの一覧


$ ruby-switch --list

ruby2.3
ruby2.4


現在、設定されているRubyを確認。

$ ruby -v

ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]






Rubyのバージョン切替


$ sudo ruby-switch --set ruby2.4

$ ruby -v
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux-gnu]
posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年06月23日

Ubuntu サーバの設定 ファイアーウォールの設定をする

Linuxには "iptables" というパケットフィルタが搭載されている。
"iptables"はちょっと設定が複雑なので、"iptables" の設定を簡単にできるようにしたGUIが、"gufw" 。



インストール


端末で実行。

$ sudo apt-get install gufw





gufw の起動


使うときはDASH検索で「gufw」と打ち、検索して使う。
gufw01.png

起動時にパスワードを求められる。
gufw02.png

起動したら、以下のようになっている。
デフォルトでファイアウォールは無効の状態。
gufw03.png






ファイアーウォールを有効にする


[Status] クリックして、"オン" にする。
gufw04.png
ファイアーウォールが有効になり、右側にある盾の絵に色が付く。


gufw05.png
有効にした状態では、外部から内部へのアクセス(Incoming)は全て拒否し、内部から外部へのアクセス(Outgoing)は全て許可する設定。

  • Allow:アクセスを許可する。
  • Deny:アクセスを拒否する。接続を無視する。
  • Reject:アクセスを拒否する。拒否されたことを接続元に通知する。

これでは、SambaSSHも接続できない。




アクセスのルールを追加する


Samba、SSH接続を可能とするために、通信ルールを追加する。

[ルール] をクリック。
gufw06.png

[+(プラス)] をクリック。
gufw07.png

[サービス] タブで、
一番下の入力欄に "smb" or "samba" と入力すると、1つ上の欄が "SAMBA" に変わる。
gufw08.png

[ポリシー] が "Allow" となっていることを確認して、
[追加] をクリックした後、[閉じる] をクリック。
gufw09.png

追加した設定ルールが一覧に表示される。
gufw10.png

続けて、"SSH" も許可する。
同じように、[ルール] をクリックして追加する。
gufw12.png
"It may be a security risk to use a default allow policy for SSH"と、セキュリティリスクになる可能性があると警告がでるが、自己責任で追加する。


Webサーバーも許可しておく。
[ルール] をクリックして追加する。
今度は、[Application] から選択してみる。"HTTP" を選ぶ。
gufw13.png


これで、"Samba"、"SSH"、"HTTP"が許可された状態になった。
gufw14.png





使用しているポートの一覧


[レポート] をクリックすると、現在、使用しているポートの一覧が表示される。
gufw11.png




CUIで操作する


CUIで操作したかったら、"ufw" を使う。

コマンド一覧を表示する

$ sudo ufw help

Usage: ufw COMMAND

Commands:
enable enables the firewall
disable disables the firewall
default ARG set default policy
logging LEVEL set logging to LEVEL
allow ARGS add allow rule
deny ARGS add deny rule
reject ARGS add reject rule
limit ARGS add limit rule
delete RULE|NUM delete RULE
insert NUM RULE insert RULE at NUM
route RULE add route RULE
route delete RULE|NUM delete route RULE
route insert NUM RULE insert route RULE at NUM
reload reload firewall
reset reset firewall
status show firewall status
status numbered show firewall status as numbered list of RULES
status verbose show verbose firewall status
show ARG show firewall report
version display version information

Application profile commands:
app list list application profiles
app info PROFILE show information on PROFILE
app update PROFILE update PROFILE
app default ARG set default application policy

ステータス確認

$ sudo ufw status

状態: アクティブ

To Action From
-- ------ ----
137,138/udp ALLOW Anywhere
139,445/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere


ファイアウォールの無効化

$ sudo ufw disable

ファイアウォールを無効にし、システム起動時にも無効にします

※SSH接続した状態で無効化しても、接続済のSSH接続は有効のままだったので、無効化する前に接続した通信は遮断されないようだ。

ファイアウォールの有効化

$ sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
ファイアウォールはアクティブかつシステムの起動時に有効化されます。


incomingのデフォルトポリシー(deny, reject, allow)の設定

$ sudo ufw default deny

デフォルトの incoming ポリシーは 'deny' に変更しました
(適用したい内容に基づいて必ずルールを更新してください)


ルールの削除

ステータス確認に、"numbered" をつけると、ルール番号を表示してくれる。

$ sudo ufw status numbered

状態: アクティブ

To Action From
-- ------ ----
[ 1] 137,138/udp ALLOW IN Anywhere
[ 2] 139,445/tcp ALLOW IN Anywhere
[ 3] 22/tcp ALLOW IN Anywhere
[ 4] 80/tcp ALLOW IN Anywhere

この番号を使い、ルールを削除する。

$ sudo ufw delete 3

削除:
allow 22/tcp
操作を続けますか (y|n)? y
ルールを削除しました


ルールの追加

$ sudo ufw allow 22/tcp

ルールを追加しました


より具体的に⁠、特定のIPアドレスからの接続を許可する場合

$ sudo ufw allow from 192.168.1.0/24 to any port 22

または、

$ sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp


これで192.168.1.0/24のみ、ポート22番へのアクセスが許可できる。

アプリケーションごとの設定

ポートに対するルール設定ではなく、サービスに対する設定を行うことができる。
まず、登録されている「アプリケーション」の一覧を調べる。

$ sudo ufw app list

利用可能なアプリケーション:
Apache
Apache Full
Apache Secure
CUPS
OpenSSH
Samba

これは "/etc/ufw/application.d/" に定義ファイルを置くことで,アプリケーションごとに接続の設定ができるようになる。
このアプリケーション名を使ってルールを設定する。

$ sudo ufw allow OpenSSH

ルールを追加しました

$ sudo ufw status numbered
状態: アクティブ

To Action From
-- ------ ----
[ 1] 137,138/udp ALLOW IN Anywhere
[ 2] 139,445/tcp ALLOW IN Anywhere
[ 3] 80/tcp ALLOW IN Anywhere
[ 4] OpenSSH ALLOW IN Anywhere



ルールの優先順位

$ sudo ufw status numbered
状態: アクティブ

To Action From
-- ------ ----
[ 1] 137,138/udp ALLOW IN Anywhere
[ 2] 139,445/tcp ALLOW IN Anywhere
[ 3] 80/tcp ALLOW IN Anywhere
[ 4] 22/tcp ALLOW IN Anywhere
[ 5] 22/tcp ALLOW IN 192.168.1.0/24

ルール登録した順([1]→[5]の昇順)で適用される。
これだと、[5]のポート22番にIPアドレスの制限を追加したのに、先に[4]が適用され、ポート22番にはIPアドレスの制限が適用されないことになる。

この状態であれば [4] を削除するだけでよいが、実際の運用では後から制限を設定したい場合がある。そのたびにルールの追加順の考慮して削除と追加を繰り返すことになると思うと手順が煩わしい。そういうときには、ルール追加時に適用位置を指定することで対応できる。

今回、IPアドレス制限の位置を[3]の次に追加しよう。
まずは、現在の[5]は一旦、削除。
$ sudo ufw delete 5
削除:
allow from 192.168.1.0/24 to any port 22 proto tcp
操作を続けますか (y|n)? y
ルールを削除しました

$ sudo ufw status numbered
状態: アクティブ

To Action From
-- ------ ----
[ 1] 137,138/udp ALLOW IN Anywhere
[ 2] 139,445/tcp ALLOW IN Anywhere
[ 3] 80/tcp ALLOW IN Anywhere
[ 4] 22/tcp ALLOW IN Anywhere

次に、再度IPアドレス制限のルールを追加するのだが、"insert" を使い、位置を指定して追加する。
[3]の次に入れたいので、[4]の位置に挿入する。

$ sudo ufw insert 4 allow from 192.168.1.0/24 to any port 22 proto tcp

ルールを挿入しました

$ sudo ufw status numbered
状態: アクティブ

To Action From
-- ------ ----
[ 1] 137,138/udp ALLOW IN Anywhere
[ 2] 139,445/tcp ALLOW IN Anywhere
[ 3] 80/tcp ALLOW IN Anywhere
[ 4] 22/tcp ALLOW IN 192.168.1.0/24
[ 5] 22/tcp ALLOW IN Anywhere



接続回数の制限

ブルートフォース攻撃対策として使える。
30秒間の間に6回以上接続を試みた IP アドレスを拒否する機能がある。
ufw supports connection rate limiting, which is useful for protecting against brute-force login attacks.
When a limit rule is used, ufw will normally allow the connection but will deny connections if an IP address attempts to initiate 6 or more connections within 30 seconds.
See http://www.debian-administration.org/articles/187 for details.
引用:man ufw

"limit" を指定する。

$ sudo ufw limit 22/tcp

ルールを追加しました

$ sudo ufw status numbered
状態: アクティブ

To Action From
-- ------ ----
[ 1] 137,138/udp ALLOW IN Anywhere
[ 2] 139,445/tcp ALLOW IN Anywhere
[ 3] 80/tcp ALLOW IN Anywhere
[ 4] 22/tcp ALLOW IN 192.168.1.0/24
[ 5] 22/tcp LIMIT IN Anywhere





まとめ


Ubuntuは、デフォルトの設定ではファイアウォールが「有効」になっていない。
"gufw" は設定すれば再起動しても、ちゃんと自動的に設定を有効化してくれるので安心。
また設定も簡単なので、外部公開しているサーバーは少しでもセキュリティを上げておきたいので、ツールを入れ、有効化しておきたい。

posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年06月22日

Ubuntu サーバの設定 SSH ログファイルの確認

SSH接続時のアクセスログを確認してみる。
接続がうまくいかないとか、不正アクセスの確認などができるようになる。


Ubuntuのログファイルは、

/var/rog/auth.log


最新のものが "auth.log" で、次が "auth.log.1" 、さらに古いものは圧縮されて "auth.log.*.gz" となっている。

ログの確認には、catコマンド、headコマンド、tailコマンド等を使う。
例:ログの最終10行分を表示

cat /var/rog/auth.log | tail -50

smbd: pam_unix(samba:session): session closed for user nobody
smbd: pam_unix(samba:session): session closed for user nobody
sshd[3270]: Connection from 192.168.1.7 port 46678 on 192.168.1.150 port 22
sshd[3270]: Connection closed by 192.168.1.7 port 46678 [preauth]
sshd[3273]: Connection from 192.168.1.7 port 46680 on 192.168.1.150 port 22
sshd[3273]: Accepted publickey for ******** from 192.168.1.7 port 46680 ssh2: RSA SHA256:62ARlxPql1k5FKpT97R/N0/zwLf6BABwSf1U3NC6f7s
sshd[3273]: pam_unix(sshd:session): session opened for user ******** by (uid=0)
systemd-logind[715]: New session 6 of user ********.
sshd[3273]: User child is on pid 3324
sshd[3324]: Starting session: shell on pts/9 for ******** from 192.168.1.7 port 46680 id 0




ログレベルの設定ファイルは、

etc/ssh/sshd_config


設定箇所は、"LogLevel" ログレベル

sshd (8) が出力するログメッセージの冗長性レベルを指定します。とりうる値は次のとおりです: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG,DEBUG1, DEBUG2 および DEBUG3。デフォルトでは INFO です。DEBUG と DEBUG1 は等価です。DEBUG2、DEBUG3 はそれぞれさらに冗長なログになります。DEBUG レベル以上のログはユーザのプライバシーを侵害するので、勧められるものではありません。
引用:OpenSSH 日本語マニュアルページ

"QUIET" はログ出力を抑止。
デフォルトは "INFO" 。情報レベルのログを出力する。


どのようなアクセスがあるのか確認するために、普段の設定は、
"VERBOSE" とし、詳細レベルの出力ぐらいにとどめる。

SSH接続がうまくいかないときには、
公開鍵と合っていないとか、パーミッションの設定などが間違っている可能性が高いので、
そういうときは、"DEBUG" に変更して、誤っている箇所を確認するようにしてみるとよい。



Ubuntu サーバの初期設定 ssh
Ubuntu サーバの初期設定 ssh(秘密鍵)
posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする