OpenSSHでリモート
注意 以下の記載は古いポストで、現在はSSH-DSS(DSA)の
脆弱性が発覚しており、DSAは使用しておりません。
dsaの部分をrsaに読み替えていただければOKなので
残しては置きますが、読み替えは必須となります。
関連記事 → こちら ←
なおUbuntu16.04LTSなどで採用されているopenSSHの
バージョンではssh-dssは使えないようになっています。
遠隔操作に使う暗号化技術は、OpenSSHで実現します。
Fedoraでは、ディフォルトでrootでのloginが可能で、
そのままrootで作業できますが、これは危険な行為です。
しかし、拙宅サーバーで行う、サーバー間でのバックアップ
において、rsyncをSSHで暗号化し、rootでの作業があります。
しかも自動なので、パスワードを打つ行程を省きます。
安全に作業するためには、なんらかの細工が必要です。
ここでは、プライベートキーとパブリックキーをペアとした
ものをお互いに持つことにより、セキュリティを確保する
説明をします。
クライアントがプライベートキーを持ち、それとペアの
パブリックキーをサーバーが持ちます。
プライベートキーを持つクライアントしかログインできないよう、
SSHのコンフィグファイルで設定します。
クライアントであるWindowsマシンから、SSHを使用して
遠隔操作をしてみましょう。
Windows側
SSHによる遠隔操作ができるアプリケーションソフトはいくつか
ありますが、ここではフリーソフトのTTSSHを使ってみます。
おなじみの窓の社からダウンロード。
http://www.forest.impress.co.jp/
ソフトライブラリ
サーバー・ネットワーク
リモート操作
Tera Term
インストール時に
TTSSHと追加プラグインのみインストール
起動したら
ホスト名 192.168.1.*** OK
次の画面で
ユーザー名 root
パスフレーズ rootのパスワード OK
ディフォルトではパスワードでrootによる
ログインが可能になっています。
まずは SELinux の機能を止めます。
# vi /etc/sysconfig/selinux
i （←INSERTモード）
SELINUX=enforcing
↓
SELINUX=disabled
ESC （←コマンドモード）
:wq （保存して終了）
Enter
# shutdown -r now （←システムの再起動）
再起動後SELinuxが無効となっています。
再度TTSSHでサーバーにログイン。
サーバーでペアキーを作成します。
自動バックアップ時にパスフレーズを聞かれないように
パスフレーズは入力しないで進んでください。
# ssh-keygen -t dsa （←ペアキーの作成）
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): パスフレーズを入力しないで
Enter same passphrase again: パスフレーズを入力しないで
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
24:61:90:28:91:6c:35:94:de:65:95:74:1e:6a:d5:12 root@ns.net-de-shopping.info
The key’s randomart image is:
+–[ DSA 1024]—-+
|ooo=ooo oo.Eo |
|oo..o. + .=… |
|… . + .o .. |
| . . o. |
| S |
| |
| |
| |
| |
+—————–+
/root/.ssh/配下にid_dsaとid_dsa.pubが作成されます。
確認するには
# ll .ssh
-rw——-. 1 root root 668 6月 14 22:54 id_dsa
-rw——- 1 root root 751 6月 14 23:44 id_dsa.pub
ll というコマンドは使用できないディストリビューション
があります。というかほとんど使用できない。。。
その場合は ls -l を使ってください。
#############################################
先頭に（.）が付されるのは隠しディレクトリ、隠しファイルです。
# ll
では、隠しディレクトリ、隠しファイルは表示されません。
# ll -a
（= ls -la)
とすると、.sshが表示されます。
#############################################
公開鍵はauthorized_keysというファイルに置いておくので、
id_dsa.pubの名前をauthorized_keys変更しちゃいます。
# mv id_dsa.pub authorized_keys
アクセス権を変更し、自分（root）だけしか見えないようにして
セキュリティを高めます。
（644などだと、セキュリティが確保できていないぞ！って怒られます。）
ちなみに.sshは700です。
# chmod 600 authorized_keys Enter
ペアキー作成時にパスフレーズを設定すると、自動バックアップ機能を
起動させた時、パスフレーズの入力を求められ、自動じゃなくなっちゃいます。
Windows側でプライベートキーを持つために、notepadなどのテキストエディタに
id_dsaをコピペして保存します。
# cat .ssh/id_dsa
—–BEGIN DSA PRIVATE KEY—–
MIIBuwIBAAKBgQCtdKE7o15RDK2VkGkgejKobbZMVQLGWgAZajyFREHm6ph5Snql
（中略）
BfyLmnfpFJKVV5FZIEQo
—–END DSA PRIVATE KEY—–
これをコピーし、Windowsのテキストエディタ（Notepadなど）にペースト。
TTSSHは、左クリックのままドラッグして反転させただけでコピーされます。
Windowsのテキストエディタ上で右クリックし、貼り付けてください。
—–BEGIN DSA PRIVATE KEY—–から—–END DSA PRIVATE KEY—–
までです。必ずこれらも含めてコピペしてください。
Windowsにおいては、アクセス権等の変更はありませんが、保存場所のみ
覚えておいてください。
次にSSHの設定ファイルを編集します。
2か所を下記のようにします。
# vi /etc/ssh/sshd_config
i ←編集モード
PermitRootLogin yes ←rootでのログインを許可
PasswordAuthentication no ←パスワードではなくカギでログインする
ESC （←コマンドモード）
:wq （保存して終了）
Enter
一度SSHをリスタートさせます。
# systemctl restart sshd.service （CentOS7)
# /etc/init.d/sshd restart （CentOS7以前のバージョン）
このときTTSSHの接続を切らないでください。
設定間違いなどで新たにログインできない場合、設定の修正などが、
遠隔ではなくサーバー上で行わなくてはなりません。
新たにTTSSHを立ち上げて、ログインしてみます。
起動したら
ホスト名 192.168.1.*** OK
次の画面で
ユーザー名 root
RSA/DSA鍵を使う にチェック
秘密キーボタンをクリックし、プライベートキーの在り処を指定。
OK
この操作でパスフレーズなしにログインできれば成功。
失敗したらアクセス権や設定ファイルなどを再確認します。
修正したらSSHのリスタートを忘れずに。
ログイン可能であれば、1つは切断してみましょう。
Windowsの流儀？で終了すると、サーバー側ではいきなり
いなくなる状態ですので、、サーバーがびっくりしないように
Ctrl+Dで終了の信号を送ります。
これで安全なログイン・ログアウトができるようになりました。
ちなみにWindows側でも、TTSSHによりペアキー作成ができます。
設定→SSH鍵生成
DSAを選択し生成。
パスフレーズは無入力。
ペアキーの保存。
id_dsa.pubをテキストエディタで開き、中身をコピペ。
サーバー側で
# vi /root/.ssh/authorized_keys
i ←編集モード
ペースト（右クリックだけでOK)
ESC （←コマンドモード）
:wq （保存して終了）
Enter
# chmod 600 authorized_keys
最後に必ず、パスフレーズでのログインはできないことを
確認しておきましょう。
これで通常のサーバーメンテをリモートで行う際は勿論、
自動バックアップをするときも、以下のように書いて
実行権をつけたものを、/etc/cron.hourly下に置いておけば、
パスフレーズを尋ねられるところでストップすることなく、
1時間おきに実行してくれます。
# vi /etc/cron.hourly/backup.sh
i ←編集モード
#!/bin/bash
# rsync -azv -e ssh /home/ユーザー名 バックアップ先サーバーIPアドレス:/バックアップ先パス（1行で）
ESC （←コマンドモード）
:wq （保存して終了）
Enter
# chmod +x /etc/cron.hourly/backup.sh
(+x で実行権をつける）
Enter
一応手動で実行してみます。
# sh /etc/cron.hourly/backup.sh
下記のように
sending incremental file list
sent 693 bytes received 123 bytes 1632.00 bytes/sec
total size is 4107 speedup is 5.03
sending incremental file list
sent 192 bytes received 17 bytes 418.00 bytes/sec
total size is 335 speedup is 1.60
sending incremental file list
oba-q/Maildir/
oba-q/Maildir/dovecot.index.log
oba-q/Maildir/cur/
oba-q/public_html/***/***.html
・
・
のように表示されるはずです。
######################################
ここから先はちょっとだけ上級編？
DSAの鍵長が今さら1024ビットでは不安でしょうが、
これを書いている時点ではOpenSSHの最新の規格が1034,2048,
3072などがOKでも、RFCに書かれたことを厳密に守ると、1024しか
使えないことになっています。
これはダイジェスト関数はSHA-１を使用となっているための縛りで、
RFCを守ることは古い規格しか使えないと同義となってしまいます。
しかし、ssh-keygenコマンドでは1024しか生成できませんが、
クライアント側のソフト（TTSSHなど）では、ダイジェスト関数を
固定したまま、2048ビットを生成するという方法もあります。
クライアント側のアプリで生成した2048ビットでの検証結果は、
なんの問題なく動いてくれましたが、RFCから外れているので、
未来永劫保証できるものではありませんが、自動バックアップ用で
パスフレーズがない状態で、若干セキュリティが弱い分、
気休めでも2048等を使用したほうがよいかも・・・です。
（上級編って思っているのは拙性だけで、実は常識中の
常識なのかもしれませぬ。。。）
