プログラミング Tips

ITエンジニアの雑記ブログ。
IT関連ニュースの考察や、プログラミングに関するTipsの備忘録として…
育児や日常の雑記帳としても、記事を投稿していきます。

プログラミングと日常生活に関する情報を発信しています。

カテゴリ: WEB

SSL証明書"Let's Encrypt"の自動更新を設定してみた!

前回投稿で、Debian9 + Apacheの環境にSSL認証設定を施してみた。その際、無料のSSL証明書Let's Encryptを用いたのだが、この証明書は「有効期限:90日」と短く、その都度証明書の更新が必要になる。

カレンダーに登録して、毎回マニュアル更新での対応も考えたが、自動更新コマンドが準備されていることがわかったので、その方法をまとめてみる。



環境

クライアントPC

  • MacOSX 10.13.4

サーバー

  • Debian9
  • Apache/2.4.25 (Debian)
  • certbot 0.10.2

サーバーへSSH接続できることを前提とする。

また、今回はroot権限でそのまま作業を行うが、セキュリティ確保の為にはroot認証は無効化することを推奨する。

サーバーの環境構築とSSH設定、root無効化などの詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
とか
SSH conf を簡単に接続する方法まとめた!
を参照

尚、当然ながら、SSH認証の設定が完了していることを前提とする。設定方法に関しては、こちらを参照

自動更新設定

冒頭に記述の通り"Let's Encrypt"の証明書有効期限は90日と短いため、定期的に更新が必要となる。裏を返すと、定期更新のための機能を備えているとも言える。

そのコマンドが

certbot renew

である。

非常に多機能且つ優秀なコマンドで、その一部を用いるだけで、90日更新の苦悩がほぼゼロになる!!

これを加味して、今回の設定作業は大きく下記2STEP

  1. certbot renewコマンドの準備
  2. Linuxのcrontabに登録


Step1. certbot renewコマンドの準備

利用するオプション:
--rsa-key-size : 認証鍵のサイズをデフォルトの2048bitから4096bit指定とする。この結果、SSL認証設定のセキュリティ強度が上がる(=第三者評価サイトの結果が【B】→【A】へアップ!!)。詳細は、こちらを参照

その結果、以下のコマンドを実行することで証明書情報の更新作業が自動化される

# 証明書有効期限が30日未満の場合、RSA:4096bitサイズの認証鍵で証明書を更新
$ certbot renew --rsa-key-size 4096

これで、認証情報を自動更新するコマンドが準備できた。

<ポイント>
勘違い防止のために説明すると、このステップは、SSL証明書の有効期限を確認して有効期限が30日未満の場合、"Let's Encrypt"サービスから新しいSSL証明書取得する部分を自動化したに過ぎない。

このコマンドを実行するタイミングは、「まだ手動のまま!!」である。よって次の手順でこのコマンドをLinuxシステムにスケジュール登録して、一定タイミングで実行されるようにする。

Step2. まずは登録前のテスト

ここからは、Linux Debianにcertbot renewコマンドをスケジュール登録して、SSL証明書更新の完全自動化を目指す!

まず以下の--dry-runオプションを使って自動更新をテストしてみる。このオプションでは、証明書は更新されずに動作確認のみ実施されるため、証明書の取得回数制限に引っかかる心配もない。詳細説明はこちら

$ /usr/bin/certbot renew --dry-run

この結果、下記のようなメッセージが出力されれば、入力したコマンドをcrontab登録しても同等の結果が得られる

ちなみに以下のメッセージでわかったことだが、RSA認証鍵サイズは既存のものを継承するらしい!!(12行目くらいに「4096bit」ってあることがわかる)事前の設定で、評価を【B】→【A】へ格上げするために、2048bitサイズを4096bitサイズへ更新したが、毎回--rsa-key-sizeオプションの付与が作業必要と考えていたが、この結果から、不要であることが判明!!

やっぱりデバック大事!!



Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/hogehoge.net.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for hogehoge.net
Waiting for verification...
Cleaning up challenges
Generating key (4096 bits): /etc/letsencrypt/keys/0002_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0002_csr-certbot.pem
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/360scene.net/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

<補足:証明書取得回数制限について>
"Let's Encrypt"では、証明書の取得回数に制限を設けている
詳細に関しては、公式サイト日本語翻訳サイトを参照

証明書を更新したら、WEBサーバーの再起動も必須!

/usr/sbin/service apache2 restart

今回servieコマンドはプルパスで指定する必要があるので、注意!!



Step.3: Linuxのcrontab登録

事前チェックが成功したので、いよいよ登録!

Linux標準のcrontabの使い方については、こちらを参考にした

OSの設定状況を確認しながら、登録まで行う

まずcronへの登録状況を確認

$ crontab -l
no crontab for root

まだ何も登録されていない

次にcrontabへ設定を登録するための準備。
下記コマンドで、編集エディタを選択。【1】のnanoを推奨していることがわかるので、「1」を選択

$ crontab -e
1. /bin/nano        <---- easiest
2. /usr/bin/vim.tiny

Choose 1-2 [1]:1

設定ファイルが表示されるので、

  • スケジュールリングのタイミング
  • 実行するコマンド

を記述。記述方法は、先ほどのサイトを参照

# 毎月1日午前3時に、
# "root"ユーザが "/usr/bin/certbot renew"を実行
# "&&"で処理を連結
# WEBサーバー"apache"を再起動
00 03 01 * * root /usr/bin/certbot renew && /usr/sbin/service apache2 restart

念のために確認。下記が表示されるので登録完了!

$ crontab -l
…
<省略>
…
00 03 01 * * root /usr/bin/certbot renew && /usr/sbin/service apache2 restart

完了!

これで証明書更新のタイミングを気にする必要がない!!



Debian9 + Apache + SSL認証"Let's Encrypt"で設定評価「A」を目指した!

前回投稿で、Debian9 + Apacheの環境にSSL認証設定を施してみた。その際、無料のSSL証明書Let's Encryptを用いた。

設定の確認&第三者評価の観点から、SSL環境を評価してくれるサービスを利用した結果、【B】判定。微妙…
「可もなく不可もなく」
「基本的な設定はできているが、もう一つ物足りない…」
の判定と判断したので、【A】以上の判定を目指してみた。

【参考】
SSL認証の評価をしてくれるサイト

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net


ゴール

SSL認証評価で【A】評価以上の取得!!

環境

クライアントPC

  • MacOSX 10.13.4

サーバー

  • Debian9
  • Apache/2.4.25 (Debian)
  • certbot 0.10.2

サーバーへSSH接続できることを前提とする。

また、今回はroot権限でそのまま作業を行うが、セキュリティ確保の為にはroot認証は無効化することを推奨する。

サーバーの環境構築とSSH設定、root無効化などの詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
とか
SSH conf を簡単に接続する方法まとめた!
を参照



Step1. 判定結果の確認

SSL認証の評価をしてくれるサイトへ適切なドメインを入力して、評価実行!

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net

ConoHaVPS_ssl1

サイト評価の結果、「RSA暗号鍵のサイズ"2048bit"がマイナス評価」ってコメントが出ていた。

確かに、certbot コマンドでSSL情報を生成した際、鍵サイズを設定した記憶がない…ということで、初期値「2048bit」出力だったおいうことが判明。

よって、この点を「4096bit」に更新して試してみる



Step2. SSL認証更新(RSA認証鍵サイズを「4096bit」に…)

上記コメントから、鍵サイズの延伸に対策の糸口を見つめて、SSL認証の差し替えを決定。

certbot renewが、鍵の更新をしてくれるコマンド。

このコマンドは、「有効期限:90日」の判定をして、30日未満だった場合、認証情報を更新してくれる優れもの!!他にも、色々かゆいところに手がとどくオプションを備えているコマンドのようなので、今後このコマンドについても調査&まとめておきたい。

今回は、一先ず評価結果「A」実現のために、既存の認証情報を更新するために使う

certbot renew --force-renew --rsa-key-size 4096

<オプション>
--force-renew : 証明書の有効期限の残りを無視して、過去に発行したすべての証明書を強制的に更新
--rsa-key-size 4096 : 「4096bit」のRSA公開鍵が使用された新しい証明書に更新

この結果、以下の類似メッセージの最後に"success"が出力されれば成功!!

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/hogehoge.net.conf
-------------------------------------------------------------------------------
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for hogehoge.net
Waiting for verification...
Cleaning up challenges
Generating key (4096 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

-------------------------------------------------------------------------------
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/hogehoge.net/fullchain.pem
-------------------------------------------------------------------------------

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/hogehoge.net/fullchain.pem (success)

今回使用したcertbot renewコマンドは、既存の証明書を自動更新してくれるため、設定ファイルに編集を加える必要がない。よって、次ステップは早速、評価!!



Step3. 第三者評価

前述の通り、certbot renewコマンドは自動更新してくれるので、ここでは確認の作業のみ。

Step1.で用いた評価サイトで再評価!!
ちなみに、キャッシュが残っていると、再評価されない可能性があるので、事前にキャッシュ(履歴)をクリアしておくことをお勧めする。その方法は、各ブラウザごとの方法にしたがってほしい。

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net

この結果、無事【A】評価!!

ConoHaVPS_ssl3


設定によっては、更に上の評価【A+】などもあるようだが、とりあえず上位評価が得られたので、今回は目的達成!!

Debian9 + Apache に"Let's Encrypt"をセットアップしてみた!!

WEBページのSSL対応はもはや避けては通れなくなってきていて、GoogleのSEOにもSSL対応是非が影響することが明確にうたわれている。参考

一方、立ち上げたばかりのサービスでに対して、最初から数万円のSSL証明書は買えない!!ということで、無料で発行される"Let's Encrypt"を適応してみたので、その手続きを備忘録としてまとめた。

"Let's Encrypt"について知りたい方は、オフィシャルサイトを参照してほしい。一応、日本語まとめサイトもあるので、合わせて読むと理解が深まると思う。

今回はConoHa VPS の "Debian9" への設定方法をまとめる。CentOS系はそこそこ情報があったのだけれど、Debian系は少なかったので…



環境

クライアントPC

  • MacOSX 10.13.4

サーバー

  • Debian9
  • Apache/2.4.25 (Debian)
  • certbot 0.10.2

サーバーへSSH接続できることを前提とする。

また、今回はroot権限でそのまま作業を行うが、セキュリティ確保の為にはroot認証は無効化することを推奨する。

サーバーの環境構築とSSH設定、root無効化などの詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
とか
SSH conf を簡単に接続する方法まとめた!
を参照

設定方法

作業手順は大きく以下の3ステップとなる

  1. Let's Encryptツールのインストール
  2. apacheのインストール
  3. SSL認証情報の設定
  4. WEBサーバーの設定
  5. WEBサーバーの再起動


Step1. "Let's Encrypt"ツール(certbot)のインストール

まず、この作業はroot権限の元で行うこと

$ apt-get update 
$ apt-get install -y certbot
$ certbot --version
certbot 0.10.2

Step2. apacheのインストール

以下のコマンドでapacheをインストール

apt-get install -y apache2

<チェック>
適当なブラウザにWEBサーバーのIPアドレスを入力し、apache初期画面が表示されることを確認する。この結果、webサーバーが正常にインストール〜起動していることがわかる
apache初期画面

Step3. SSL認証情報の設定

以下のコマンドを実行して、SSL認証ファイルを生成する

# certbot certonly --webroot -w <ドキュメントのルートPATH> -d <ドメイン名>
$ certbot certonly --webroot -w /var/www/html -d hogehoge.net

この結果、以下のような表示になれば成功

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):hoge@hoge.jp    # ←入力

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A      # ←入力
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for hogehoge.net
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/hogehoge.net/fullchain.pem. Your cert will
   expire on 2018-07-24. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to hoge@hoge.jp.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le


このメッセージ中で重要な部分は、IMPORTANT NOTES:以降にある証明書や秘密鍵などに関する情報。ココには、それらの鍵ファイルを出力したパスが載っていて、この例の場合は、/etc/letsencrypt/live/hogehoge.net/ディレクトリ内に各種鍵が格納されていることがわかる。これら鍵ファイルは次ステップでサーバー設定に必要となる。

Step4. WEBサーバーの設定

以下のコマンドでWEBサーバーのSSL設定ファイルを編集

# オリジナルのファイルを別名でコピーしておくと安心
$ cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.org
$ nano /etc/apache2/sites-available/default-ssl.conf

ファイルが開いたら、以下の部分を編集(加筆、修正)する。場合によっては、行の先頭に#が付与されている場合も考えられるが、この場合、#はコメントアウトの意味なので削除!!

ServerName hogehoge.net
DocumentRoot /var/www/html

SSLEngine on
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC$
SSLHonorCipherOrder on
SSLOptions +StrictRequire

SSLCertificateFile /etc/letsencrypt/live/hogehoge.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/hogehoge.net/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/hogehoge.net/chain.pem

Step5. WEBサーバーの再起動

順番に以下のコマンドを実行して、設定を反映&再起動!!
毎回、apacheの再起動を促されるが、最後に一回実行すればいい!!

$ a2enmod rewrite
Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2
$ a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  systemctl restart apache2


$ a2ensite default-ssl.conf
Enabling site default-ssl.
To activate the new configuration, you need to run:
  systemctl reload apache2

最後に再起動!!

$ service apache2 restart

まとめ

この結果、ブラウザへ https://hogehoge.net を入力すると、無事SSL通信できていることがわかる!!

ConoHaVPS_ssl2

<補足>
以下のサイトに自分のドメイン名をセットすると、SSL証明のテストを行なって、判定してくれる

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net

今回の結果、【B】判定だった。原因はRSA暗号が"2048bit"であることらしい。【A】判定を目指して、4096bitを今後の課題とする

ConoHaVPS_ssl1

以上、今日はここまで!!



参考サイト:
https://www.itzgeek.com/how-tos/linux/how-to-install-lets-encrypt-on-centos-debian-ubuntu-running-apache-web-server.html




リモートリポジトリーの変更をサーバー側へ反映する方法まとめてみた!

勉強を兼ねて、WEBアプリの開発をしているのだが、デプロイする際、gitコマンドで悩んだので、備忘のためにもまとめておく。

普段から、Gitを用いての開発は行なっているのだが、SourceTreeなどのいわゆるGUIベースのツールでサラサラっと流してしまっていたので、いざWEBサービスのデプロイに際して、CUI(コマンドライン)ベースで操作するにちょっと詰まった。

間違えた操作をしてもいいか!?と割り切りも考えたが、WEBサービスの場合は一旦デプロイ済みだと突然サービスが死ぬ、もしくはおかしくなってしまうことが考えられ、結果既存ユーザーのユーザビリティ低下は半端ない…よって、やっぱり慎重にやらなきゃね!?ってことです。

この点、単純なネイティブアプリの開発とは違うところだな〜と、一つ勉強になった。

そもそもいきなり本番サーバーにあげるのではなく、一旦テスト環境にデプロイして、最終検証後のリリースが然るべき手続きではあるが、今は勉強中でもあるので、そこのところは割り切り!!

今後、デプロイの自動化もやってみたい
<イメージ>

  1. ローカル開発
  2. リポジトリへgit push
  3. テスト環境で自動検知 & 更新(git pull)
  4. テスト環境で自動テスト (& エラーがあったら通知)
  5. 本番環境でテスト成功を検知 & 更新(git pull)
    が、とりあえずは先の話。


環境

クライアントPC

  • MacOSX 10.13.4

サーバー

サーバー側の環境には依存しない
但し、サーバーへSSH接続できることを前提とする。

サーバーの環境構築とSSH設定の詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
SSH conf を簡単に接続する方法まとめた!
を参照

あと肝心のgitがインストールされていること

gitのインストール方法

Debian(もしくはUbuntu)へのインストール

$ apt-get install git

Step1. ローカルの変更をリポジトリにpush

本稿のメインではないので詳細は割愛するが、ローカル(手元)でWEBアプリを開発し、一通りのデバックが完了したら、いよいよデプロイできるので、全てのコードをgit pushすして、リモートリポジトリへ!!

ちなみに
gitのインストールに関しては、GUIベースのツールsource treeをインストールすると全て解決する



Step2. サーバー側のコードを更新

ローカルで完成したアプリをgit pushしたら、サーバー側ではリモートリポジトリからそれらを入手して、更新が必要になる。この結果WEBサービスが最新へと更新される。

まずサーバー側に変更がないことを確認

$git status
On branch master
Your branch is up-to-date with 'xxx/master'.
nothing to commit, working tree clean

基本的にサーバー上で直接コードを編集することはないので、nothing to commit, working tree clean(訳:特に変更はないよ)であることを確認

以下のコマンドで、最新のコードを入手

$ git pull

エラーメッセージが出なければ完了!非常に簡単!!

<ポイント>
どこのリモートリポジトリからgit pullしてくるか?に関しては以下のコマンドを実行するとわかる

$ git remote -v
bitbucket https://hogehoge@bitbucket.org/hogehoge/xxx.git (fetch)
bitbucket https://hogehoge@bitbucket.org/hogehoge/xxx.git (push)

補足:pullfetchの違い

gitコマンドを調べていくと、pullfetchが似ていることがわかる。
今回もここで少し悩んだので、ざっと違いをまとめてみる。

git pull

リモートリポジトリからデータを全て取ってきて、手元のデータを更新!!
手元とリモートを同じ状態にするので、「同期」するイメージ。
この場合、mergeしたい変更がある場合には大変なことになるので、注意が必要!!

最悪、事故ってgit pullしちゃった場合も、戻したい先のIDを調べて、
git reset --hard ID--
で元に戻せるから大丈夫!!

<ポイント>
一応事前のgit statusで確認、回避できるから安心

git fetch

リモートリポジトリの変更履歴だけをとってくる。手元のデータは更新しない!!
リモートと手元と同じブランチで作業していて、且つmerge情報がある場合にはこちらがオススメ!!



SSH conf を簡単に接続する方法まとめた!

ConoHa VPSに、Debian OSを構築し、WEBアプリをデプロイする方法をまとめた。
その折、サーバーにSSH接続環境を構築することが最初のSTEPにあったが、毎回SSHコマンドにオプション、秘密鍵のパス、ホスト名、ユーザー名などを付与するのは手間…

今は管理する環境が限られているから問題ないが、今後増えて行くことを考えると、効率的に慣るする方法がないか?を調べてみた。

その結果、SSHコマンド専用のconfigファイルを準備し、その中に設定情報をまとめて記入しておくことが可能ということがわかった!!

これは便利だ!!

ということで、以下にその情報をまとめてみた



環境

クライアントPC

  • MacOSX 10.13.4
  • OpenSSH_7.6p1, LibreSSL 2.6.2

サーバー

サーバー側の環境には依存しない
但し、サーバーサイドのsshd_configファイル内の設定は、下記同等であることを前提とする。

#sshd_config設定内容
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

サーバーの環境構築とSSH設定の詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
を参照

ゴール

今回ssh_donfigを取り入れると、下記1行でサーバーに一発接続が可能になる

$ ssh hoge.com

これまで使っていた

$ ssh -i "秘密鍵" <username>:<HostName> -p <Port番号>

など、秘密鍵やポート番号、サーバーのユーザ名やホスト名の入力が不要になる

この設定で幸せに慣れること

  1. とにかく、毎回面倒な入力が減る!
  2. gitなどの分散型チーム開発で無駄な設定が減る&管理しやすくなる!

早速、その為の手順を以下にまとめる



Step1. 設定ファイルの編集

MacOSXの場合、~/.ssh/ssh_configファイルに設定情報を入力する為、下記コマンドから編集する

vi ~/.ssh/ssh_config

もしviエディタに不慣れな場合は、nanoエディタでもOK!

<ポイント>
パスにある通りこの設定ファイルは、現在のユーザーに限定して有効である。
管理者権限のユーザーに共通した設定を準備する場合には、
/etc/ssh/ssh_config
に入力する必要がある

Step2. サーバー接続の為の情報を追記

まず記述項目を以下に列記

キーワード 内容
Host ホスト名
HostName ホストのアドレス
User ログインユーザー名
IdentitiesOnly 秘密鍵が必要か?
IdentityFile 秘密鍵ファイル(パス含む)
Include 分散したconfigファイル読込む(分割/分散管理を実現)
Port 接続用ポート番号(Default:22)
ServerAliveInterval サーバー応答なしの場合、タイムアウトまでの時間(秒)
TCPKeepAlive サーバー接続を継続するか?


この他にも様々な設定キーワードがある。詳細を確認する場合は、下記コマンドで確認可能

$ man ssh_config

必要なキーワードをssh_configファイル内に記載
今回は下記情報と仮定して入力する。

<ポイント>
Hostをメインに、それ以外の設定内容はインデントを下げること!

#hogehoge.net
Host hogehoge.net
  HostName xxx.xxx.xx.xxx
  User hoge
  IdentityFile ~/.ssh/id_rsa_secret_key

Step3. サーバーに接続

下記コマンドでサーバーに接続する

# ssh <ホスト名>
$ ssh hogehoge.net

下記エラーが発生した場合する可能性

ssh: Could not resolve hostname hogehoge.net: nodename nor servname provided, or not known

エラーは~/.ssh/ssh_configを参照できていないことが原因と考えられる為、該当するssh_configファイルをオプション指定する

$ ssh -F .ssh/ssh_config hogehoge.net

もしくは、/etc/ssh/ssh_config<STEP.2> の追加内容を記載

以上、完了!!



↑このページのトップヘ

-->