2日目　ファイアウォールとSSH

まだSSHは使えないので、Proxmoxのコンソールで操作します。先に22番の許可を登録し、それからファイアウォールを有効にします。

sudo ufw allow 22/tcp
sudo ufw enable

ufw enable を打つと Command may disrupt existing ssh connections. Proceed with operation (y|n)?（今のSSH接続が切れるかもしれないが続けるか）と聞かれるので、y と答えます。Firewall is active and enabled on system startup と出れば有効になり、次に起動したときも自動で有効になります。

ufwを有効にすると、初期状態では「外から入ってくる通信はすべて拒否、中から外へ出ていく通信はすべて許可」になります。許可を登録したポートだけが、例外として通れます。

sudo ufw status numbered
sudo ss -tuln

ufw status numbered は、門番の許可リストを番号つきで表示します。1エビデンス1の撮影ポイント撮影ポイント　エビデンス1手順2で sudo ufw status numbered を実行した直後。Status: active と、22/tcp の ALLOW IN だけが並んでいることが分かるように撮る。エビデンス一覧の項目へ移動 ↓

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 22/tcp (v6)                ALLOW IN    Anywhere (v6)

Status: active は有効であること、22/tcp ALLOW IN Anywhere は「どこからでも、22番宛てに入ってくる通信を許可」という意味です。(v6) はIPv6という新しい形式のアドレス向けの同じ規則です。

ss -tuln は、サーバーの中でどのポートを待ち受けているかを表示します（ssのオプションの意味）。

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
udp   UNCONN 0      0         127.0.0.54:53         0.0.0.0:*
udp   UNCONN 0      0      127.0.0.53%lo:53         0.0.0.0:*
tcp   LISTEN 0      4096   127.0.0.53%lo:53         0.0.0.0:*
tcp   LISTEN 0      4096      127.0.0.54:53         0.0.0.0:*
tcp   LISTEN 0      4096               *:22               *:*

*:22 や 0.0.0.0:22

どの宛先アドレスでも22番で待ち受けている。これがSSHの窓口

127.0.0.53:53 など

Ubuntuが自分用に使っている名前の問い合わせの係。127で始まるアドレスは自分自身にしか届かないので、外からは使えない

ここで大事なのは、ufwの許可リストと待ち受けの一覧が別のものだということです。前者は「門が開いているか」、後者は「窓口に人がいるか」を表しています。

外から見たときに、許可したポートにはつながり、許可していないポートにはつながらないことを確かめます。Windowsのターミナルで次の3つを実行します。6エビデンス6の撮影ポイント撮影ポイント　エビデンス6手順3で Test-NetConnection を22番・80番・443番の順に実行し終えた時点。3つの TcpTestSucceeded（True と False）を見比べられるように撮る。1画面に収まらなければ分けて撮り、図の番号も分ける。エビデンス一覧の項目へ移動 ↓

Test-NetConnection 192.168.100.xxx -Port 22
Test-NetConnection 192.168.100.xxx -Port 80
Test-NetConnection 192.168.100.xxx -Port 443

ComputerName     : 192.168.100.107
RemoteAddress    : 192.168.100.107
RemotePort       : 22
InterfaceAlias   : イーサネット
SourceAddress    : 192.168.xx.xx
TcpTestSucceeded : True

最後の行 TcpTestSucceeded が True なら接続成功、False なら失敗です。80番と443番では、しばらく待たされたあとに警告（TCP connect to … failed）が出て False になるはずです。待たされるのは、ufwが断りの返事もせずに黙って通信を捨てるため、Windows側が返事を待ち続けるからです。考察のヒント考察のヒント80番と443番は、今はサーバーの中で何も待ち受けていないので、ファイアウォールがなくてもつながりません。「つながらなかった」ことをファイアウォールの効果だと言い切れるかは、手順2の2つの一覧（許可リストと待ち受け）を見比べて考えます。考察のヒント考察のヒント「しばらく待たされてから失敗」と、すぐに断られる Connection refused は、失敗のしかたが違います。前者は門（ufw）で黙って捨てられた、後者は門は通ったが窓口に誰もいなかった、という違いで、結果の読み取りの深さを示せます。

22番が開いていることが確かめられたので、WindowsからSSHでサーバーに入ってみます。

ssh t3admin@192.168.100.xxx

初めて接続するサーバーでは、次のように聞かれます。

The authenticity of host '192.168.100.107 (192.168.100.107)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

「このサーバーとは初対面ですが、本物ですか？」という確認です。サーバーにも固有の鍵があり、その指紋（フィンガープリント）がWindows側に記録され（known_hosts）、次回からは同じサーバーかどうかを自動で確かめてくれます。yes と最後まで打って Enter を押します。考察のヒント考察のヒント鍵認証が「利用者が本人か」をサーバーが確かめる仕組みなのに対し、この指紋の確認は「サーバーが本物か」を利用者が確かめる仕組みです。確かめる向きが2つあることに触れると、SSHの安全性の考察が深まります。

続けてUbuntuのパスワードを（見えないまま）入力し、プロンプトが t3admin@t3lab-XX:~$ に変われば、あなたは今、Windowsの窓からサーバーを操作しています。確認できたら exit で抜けます。

exit

WindowsのPCの中に、秘密鍵と公開鍵の組を作ります。指導書には2つの方法が書かれていますが、どちらも最後は同じ ssh-keygen コマンドで作ります。保存先のフォルダ .ssh がまだないと失敗することがあるので、先にフォルダを作る「方法2」の書き方が確実です。

New-Item -ItemType Directory -Force -Path $env:USERPROFILE\.ssh
ssh-keygen -t ed25519 -C "t3-lab" -f $env:USERPROFILE\.ssh\id_ed25519
Get-ChildItem $env:USERPROFILE\.ssh\id_ed25519*

$env:USERPROFILE は、Windowsの自分のユーザーフォルダ（C:\Users\あなた）を表す環境変数です。途中で次のように聞かれます。

Enter passphrase (empty for no passphrase):

秘密鍵のファイルにかける合言葉（パスフレーズ）。入力は見えません。何も打たずに Enter を押すと合言葉なしになる。どちらにするかは授業の指示に従う

Enter same passphrase again:

確認のため、同じものをもう一度

… already exists. Overwrite (y/n)?

同じ名前の鍵がすでにある、という確認。基本は n。y にすると古い鍵は消え、その鍵を登録してあるサーバーには入れなくなる

最後の Get-ChildItem で、id_ed25519（秘密鍵）と id_ed25519.pub（公開鍵）の2つが表示されれば完成です。2エビデンス2の撮影ポイント撮影ポイント　エビデンス2手順5で鍵を作った直後。ssh-keygen の結果（Your identification has been saved in …）と、続けて実行した Get-ChildItem の2つのファイル名が1枚に入るように撮る。確認コマンドで鍵を作り直すと上書きを聞かれるので、この時点で撮っておく。エビデンス一覧の項目へ移動 ↓

作った公開鍵をサーバーに運び、「この鍵ならログインしてよい」という名簿（authorized_keys）に書き加えます。この段階ではまだパスワード認証を残しておき、パスワードでログインして作業します。Windowsとサーバーを行ったり来たりするので、下の表で場所を確かめながら進めます。

6-1　パスワードでサーバーに入る

ssh t3admin@192.168.100.xxx

6-2　置き場所と名簿を作る

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

700 は「所有者だけが中に入れる」、600 は「所有者だけが読み書きできる」というパーミッション（権限）です（権限の計算機）。SSHのサーバーは、名簿がほかの人にも書き換えられる状態だと、他人が勝手に鍵を足せてしまうため、その名簿を信用しません。考察のヒント考察のヒント名簿の権限を絞るのは、他人が勝手に鍵を書き足せないようにするためです。「守る仕組みそのものも守る必要がある」という視点は、セキュリティの考察で使えます。

6-3　いったんWindowsに戻る

exit

6-4　公開鍵のファイルを送る

scp $env:USERPROFILE\.ssh\id_ed25519.pub t3admin@192.168.100.xxx:~/id_ed25519.pub

送り先の ユーザー名@IPアドレス: の後ろがサーバー側の場所です。パスワードを聞かれるので入力します。

6-5　もう一度パスワードで入る

ssh t3admin@192.168.100.xxx

6-6　名簿に追記する

cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
rm ~/id_ed25519.pub

cat でファイルの中身を出し、>> で名簿の末尾に追記します。> 1つだと上書きになるので注意します（リダイレクト）。追記したら、運んできたファイルは用済みなので消します。cat ~/.ssh/authorized_keys で、ssh-ed25519 AAAA… t3-lab のような1行が入っていることを確かめられます。

6-7　Windowsに戻る

exit

6-8　鍵でログインする

ssh -i $env:USERPROFILE\.ssh\id_ed25519 t3admin@192.168.100.xxx

-i は「この秘密鍵を使う」という指定です。既定の名前（id_ed25519）で作った場合は、-i 以降を省いて ssh t3admin@192.168.100.xxx だけでも自動で使われます。

鍵でログインできることを確かめたら、SSHのサーバーの設定ファイルsshd_configを書き換えて、鍵以外のログインを受け付けないようにします。手順6-8で鍵でログインした状態から始めます。

書き換える前に、元のファイルのコピーを取っておくと安心です。

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

ファイルの中から次の4つの項目を探し（nanoでは Ctrl+W で検索）、行頭に # があれば消して、値を次のようにします。

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

このファイルでは、同じ項目が何度も書かれていると最初に書かれた値が使われます。ファイルの末尾に同じ項目を書き足すのではなく、もともとある行を直すようにします。保存したら、書式の確認と再起動をします。

sudo sshd -t
sudo systemctl restart ssh
sudo systemctl status ssh

sshd -t は、設定ファイルに書き間違いがないかを調べる命令で、何も表示されなければ問題なしです。エラーが出たら、表示された行を直してからもう一度実行します。status で active (running) を確かめます。3エビデンス3の撮影ポイント撮影ポイント　エビデンス3手順7で設定を保存したあと、sudo sshd -t（何も表示されない）と sudo systemctl status ssh（active (running)）を続けて実行した直後。2つのコマンドが1画面に入るように撮る。エビデンス一覧の項目へ移動 ↓

最後に、Windowsのターミナルで新しいタブを開き、鍵でログインできることを確かめます。4エビデンス4の撮影ポイント撮影ポイント　エビデンス4手順7の最後、パスワード認証を禁止したあとで、Windowsのターミナルの新しいタブから ssh -i … を実行し、パスワードを聞かれずにプロンプトが t3admin@t3lab-XX:~$ に変わった時点。打ったコマンドの行も写るように撮る。エビデンス一覧の項目へ移動 ↓

ssh -i $env:USERPROFILE\.ssh\id_ed25519 t3admin@192.168.100.xxx

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin'
ls /etc/ssh/sshd_config.d/

WindowsからサーバーへファイルをSSHの仕組みで送り（アップロード）、サーバーからWindowsへ受け取ります（ダウンロード）。

まず、送るための sample.txt を作ります（指導書には作り方が書かれていません）。Windowsのターミナルで、今いるフォルダ（プロンプトに表示されている場所）に作られます。

Set-Content -Path .\sample.txt -Value "hello from windows"
scp .\sample.txt t3admin@192.168.100.xxx:~/sample_from_win.txt
scp t3admin@192.168.100.xxx:~/sample_from_win.txt .\sample_from_server.txt
Get-Content .\sample_from_server.txt

2行目が「Windows → サーバー」、3行目が「サーバー → Windows」です。scp 送り元 送り先 の順は変わらず、サーバー側だけに ユーザー名@IPアドレス: が付きます。鍵認証を設定したので、パスワードは聞かれません。5エビデンス5の撮影ポイント撮影ポイント　エビデンス5手順8で2つの scp を実行し終えた直後。送信と受信の両方の行（100% と表示される転送の結果）と、Get-Content で中身を表示した結果が1枚に入るように撮る。エビデンス一覧の項目へ移動 ↓

サーバー側でも届いていることを確かめます。

ls -l ~/sample_from_win.txt