勉強記録）SSH
GeminiさんにフォローしてもらってSSHについて勉強した記録です
SSH学習記録
SSHはあまり意識していないが、あちらこちらで利用している。ただ手順を辿っているだけであり、どのような構成になっているのか、環境として何が必要なのかわかっていない。一度きちっと理解したい。
学習項目
- 概念理解
- ハンズオン
概念理解
1. SSHとは
SSH（Secure Shell）は、ネットワーク経由で別のコンピューターに安全に接続し、コマンドを実行したり、ファイルを転送したりするためのプロトコルです。
2. 役割
暗号化された通信路を提供することです。
安全なリモートログイン
通信内容はすべて暗号化される
安全なファイル転送
SCPやSFTPを利用し、暗号化された安全な方法でファイルの送受信を行う。
3. 構成要素
- SSHクライアント
PuTTYやTera Termといったソフトがこれに該当する
- SSHサーバ
ポート22で待ち受ける
4. 認証方式
パスワード認証
ユーザー名とパスワードを、SSHの暗号化されたセッション経由でサーバーに送信し、サーバー上のアカウント情報と照合します。
公開鍵認証
クライアント側で作成した秘密鍵と公開鍵のペアを使用します。公開鍵をサーバーに登録し、クライアントは接続時に秘密鍵の所有を証明することで認証します。秘密鍵はパスフレーズで保護されます。
キーボードインタラクティブ認証
サーバーがクライアントに対して チャレンジ（質問）を送り、クライアントがそれに対するレスポンス（応答） を返すことで認証を完了します。質問と応答の回数や内容はサーバー側で自由に設定できます。
ホストベース認証
サーバー側が、接続元のホスト名と、そのホストの鍵（ホストキー）の正当性を確認することで、ユーザーの認証を行います。ユーザーごとのパスワード入力は不要になります。
5. 公開鍵認証
パスワード認証よりもセキュリティが高く、かつ自動化しやすいため、実務ではこちらが主流です。
仕組みの概要
- 鍵ペアの作成: クライアント側で秘密鍵と公開鍵のペアを作成します。
- 公開鍵の配置: 公開鍵を、接続したいサーバー側の特定の場所（通常は ~/.ssh/authorized_keys ファイル）に配置します。
- 接続: 接続時、クライアントは秘密鍵を提示し、サーバーはそれに対応する公開鍵で認証を行います。
鍵ペアの作成（クライアント側）
ssh-keygen コマンドを使用します。
Bash（Windowsでも可） ssh-keygen -t rsa -b 4096
- 鍵の種類 (-t) はRSAやEd25519などが使われます。
- 鍵のビット数 (-b) は4096が推奨されます。
- 作成時に入力を求められるパスフレーズは、秘密鍵を保護するためのパスワードです。設定を強く推奨します。
公開鍵の転送（クライアントからサーバーへ）
最も簡単な方法は ssh-copy-id コマンドです。
Bash（Windowsでは手作業でサーバ反映） ssh-copy-id -i ~/.ssh/id_rsa.pub [ユーザー名]@[ホスト名またはIPアドレス]
6. セキュリティのヒント
SSHは便利ですが、セキュリティ対策が非常に重要です。
- 公開鍵認証の利用: パスワード認証を無効化し、公開鍵認証のみを使用する。
- パスフレーズの設定: 秘密鍵には必ずパスフレーズを設定する。
- ポート番号の変更: 標準のポート22から、任意の高い番号のポートに変更する (Port Knockingという手法もあります)。
- ルートログインの禁止: rootユーザーでの直接ログインを禁止する。
- ファイアウォールの設定: 接続元IPアドレスを制限する。
公開鍵認証で使う秘密鍵ファイル自体を、さらに別のパスワードで暗号化して保護することです。これは、金庫の中に入れた重要な書類（秘密鍵）を、さらに別の鍵（パスフレーズ）でロックするようなイメージです。
7. プロダクト
- サーバ：OpenSSH
- キー生成：ssh-keygen（*1）、PuTTYgen
- キー格納：プロダクトなし。OpenSSHの~/.ssh/authorized_keysへ追記する。
- シェル（接続）：ssh（*1）、PuTTY、Tera Term
- ファイル送受信：scp（1）、sftp（1）、WinSCP
- *1：OpenSSHに含まれる
コマンド例
| ツール | 使用例 |
|---|---|
| ssh | ssh -p 2222 user@192.168.1.100 -i id_rsa_taro |
| scp | scp localfile.txt user@server:/home/user/ |
| ssh-keygen | ssh-keygen -t ed25519 |
| ssh-copy-id | ssh-copy-id -i ~/.ssh/id_rsa.pub user@server:/home/user/ (Linuxのみ) |
OpenSSHサーバ環境構築
利用環境：Windows 11 Home
1. インストール
サーバー
- ［設定］-［システム］-［オプション機能］-［オプション機能を表示または編集する］
- ［機能を表示］-［使用可能な機能を表示する］
- 表示された機能より"OpenSSHサーバ"を選択して実行する
クライアント
すでにインストール済みであった。OpenSSHサーバ同様にオプション機能の選択でインストール可能と思われる。
2. 設定
サーバー
- Windows Defender ファイアウォールの設定
- sshd_configファイルの編集
設定内容
C:\ProgramData\ssh\sshd_config
設定項目 推奨設定 説明 Port 2222 など、デフォルト（22）以外の番号 自動攻撃からの防御のため、ポート番号を変更します。 PubkeyAuthentication yes 公開鍵による認証を許可します。 PasswordAuthentication no パスワードによる脆弱なログインを防ぎます。 PermitRootLogin no rootに相当する管理者アカウント（Administrator）による直接ログインを禁止します。 AllowUsers 許可するユーザー名 接続を許可するWindowsアカウント名を明記します。 Match Group Administrators 特定のグループのみにSSHアクセスを許可する場合に使用します。（任意） Protocol 2 sshサーバへのアクセスをバージョン2だけに限定します StrictModes yes ホームディレクトリ、~/ssh、authorized_keysの権限設定をチェックします。 SyslogFacility LOCAL0 ログの出力先をファイルにします。（任意） LogLevel DEBUG3 デバッグレベルのログを出力します。（任意） - 設定反映
- sshdを再起動する
- 接続ユーザ追加
- 鍵ペア作成（taroでログインして実施）
- 公開鍵認証の設定
- 秘密鍵
- SSH再起動
クライアント
今従事しているプロジェクトのプログラム設をネタに設計について考える その２
現行システムのプログラム設計問題点（元記事から転記）
- プログラム間で統一されていない
- モジュール変数が多用されている
- 抽象化や部品化が進んでいない
- 依存が複雑
- コメントが役に立たない
- 構造を示すドキュメントがない
モジュール変数が多用されている
もう少し具体的に
- VB.NETのプログラムだがクラスではなくModuleを使っている。
- プログラム全体で使用される情報は、グローバル変数のように仕様書上に定義されており、Moduleを使って実装されている。（以降グローバル変数と記す）
- Formクラスのメンバ変数も存在している。基本的にメイン画面１画面であるため、メンバ変数とグローバル変数で違いがなく、同じように使われているし、見ている方としても違いを識別しなかった。
- 各変数の役割とライフサイクルが不明瞭であった。
- 仕様書上の説明は１行簡単に用途が記載されているだけである。
それがどう困るのか
モジュール変数だから悪いわけではないが、どこからでも利用できることで、やはり各関数（処理）の結合度が高くなっている。
- どこで更新しているのかわからない。
- ある関数の同じ処理をしていても、モジュール変数が取りうる状態が不明瞭であり、考慮すべきケースがわからなかった。
- どんなルールで管理されているのか／ライフサイクルがわからないため、ある処理から利用していいのかわからない。
- 自分はテストなので不具合修正はしていないが、テストを進めるために暫定対処することがあった。問題がおきた処理・時点でモジュール変数で保持している情報を利用することがあった。しかしこの修正が常に適切なのかは全く判断がつかなかった。
結局は処理（利用する側）次第だが、どうしても使える状態にあれば使ってしまう。そういう意味では「させない」「出来ないようにする」ことも、全体を統制するうえでは大切なことだと感じた。そうしないと何も考えない人はやってしまう。できることが多いほど、バグを作りやすいのかもしれない。割れ窓の理論に近いところがあるかもしれない。悪いお手本が目の前にあると、他の人もやってしまう。だから「できない」ようにして置かなければならない。
どうすればよかったのか
これはなかなか難しい。多分このPGはVB6などの時代から存在しており、少しずつプラットフォームを変えてきたのだと思われる。当時はオブジェクト指向というよりは機能毎にクラスもしくはモジュールを作っていた時代である。また１画面１フォームに主な処理を実装するモノリシックな構造が普通であった。ではどうすればよかったのか。
- 整理と文書化
- 文書化して見えるようにすることが重要と思う。そもそも逸脱しているのか判断出来なければ守ることも出来ない。
変数は使われる側なので、変数自体で解決はできない。やはり処理側の見直しが必要である。各処理はできるだけ直接参照を避け、パラメータとして受け取るようにする。その結果、モジュール変数の利用箇所は、幹になる処理に限定されていく。そうなれば見通しがグッと良くなるはずだ。またパラメータ化した際に、モジュール変数に対するアクセス状況も理解が進み、整理できると思われる。
補足
嫌な体験は吐き出してスッキリしたい
この数日の間に、とても嫌な体験をしました。ずっともやもやが続くので、ここで成仏させたいです。
ざっと概要
- 火曜日、水曜日で基幹系システムと対向テストを行った。
- なんの準備もなく迎え、見事にミスが多発した。
起きたこと
- 無計画で当日を迎えた。
- データの準備だけで１日を費やす。
- 最後のバッチがエラー終了になる。
- 最後のバッチが正常終了しているけれど、途中でOracleエラーのメッセージが出力される。
- 最後のバッチが１件しか送信していない。
- どうしても送信対象が作られない。
- レコード作成時に設定されるFK項目がおかしい。
- ビルドにあたふた
- 送信先が違っていた
順番に見ていこう
無計画で当日を迎えた。
- 火曜日、水曜日がテスト実施日であった。
- 火曜日の朝、どういう段取りかリーダーに尋ねた。しかし一切準備なし。
- 自分は前日休出して、段取りが必要なことのリストアップ、対象データの整理、プログラムの実行順序と担当だけ整理しておいた。このテストの本来の目的である、拠点システムが出力した実績を基幹系へ送り、正常に処理されることを確認する。そのために基幹系から受け取った計画にしがって拠点システムを動かす段取りを考えていた。
- しかし火曜日朝時点で何も考えていないリーダー。とことん詰めた結果、対向前に実施した単体テストの環境で出力した実績データだけ格納してくれた後はやる、と。シナリオに乗っ取らず、しかく各自バラバラで実施して出力された実績を集めて送る。やっつけも良いところ。
データの準備だけで１日を費やす。
- 使うデータなどは整理していたので、それをメンバーに共有して実績出力を実施した。
- これだけで１日目は終了してしまった。
- リプレイス後の構成についてはまだ未決定であったり、そもそもテスト担当していないシステムだったこともあって、幾分あやふやなところがあった。
- 一部、翌日に開発側への確認を残してしまった。
最後のバッチがエラー終了になる。
- 二日目はメンバー一名、直接システム・テストに関わらないサブリーダー（的な方）、リーダーで対向テスト実施となった。
- 夕刻になっても終わっていない模様で尋ねると、何かエラーが起きているが出力がなくわからないとのこと。
- このシステムはDB接続後、エラー情報はDBへ記録されるのを知っていたので確認して共有した。
- 動かしているバッチがどこへログ出力するのか、それもわからずにテストをしている。ちなみにこのやり取りは、過去に何度もやっているので、覚えていたらすぐ対応出来たことなだ。
最後のバッチが正常終了しているけれど、途中でOracleエラーのメッセージが出力される。
- 何故かOracleのスキーマに関するエラーメッセージが出力されていた。
- シンプルなバッチでそんなおかしいところもなさそうであった。とりあえず切り分けが必要なので、どこで起きているかわかるようログを入れてもらった。（因みに退社後、テレワークで様子を見に来た結果）
- この操作を担当しているメンバーがまたあやふやで、どこどこ？どれどれ？なになに？状態で全く進まない。
- ログを入れてみると、何故かOracle接続処理の中で起きている。接続に使用しているアカウントやSIDが問題ないのは確認できている。
- 原因はなんと単体環境に追加していたOS認証パッチであった。なんで単体テスト用パッチを当ててるのか！？何が何故何のためにあるのか、全く理解していない。
最後のバッチが１件しか送信していない。
- エラー調査用に入れらログを見て気付いた。どうも１件しか送っていない。今回このバッチで送られるデータは４件のはず。
- さっきのOS認証のエラーは実行自体には影響なかったので、先に送られていたのかもしれない。大本になるテーブルの登録状況を確認すると、１件しか対象となる状態（製造完了）になっていない。なぜ？
- それにしても、何があるべき姿か（この場合はどの実績が送られるべきか）わかってないし、確認もしていない。
どうしても送信対象が作られない。
- 送られているデータもどうも違う。なぜ？
- バッチのSQLを抜き出して確認するがおかしいところは見当たらない。
- 仕様書なども再確認するが・・・
レコード作成時に設定されるFK項目がおかしい。
- 大元レコードが保持している、指示情報のキー値がどうも違う。
- バッチから抜き出したSQLでは正しく取得できている。なぜ？
- 何度も確認するが、どうも取得する条件が想定通り作用していない。
- ！？ふと気づいた。バッチが最新バージョンじゃないのでは？？？確認すると刷新していないという。なぜ？わざわざ試験環境のバッチが古いから刷新が必要と伝えてあり、ユーザへ最新バージョンの確認まで実施していたのに・・・開発側リポジトリも最新であり、そこから取得すれば良い、というのが確認結果だった。だからそのソースでビルドデプロイしてくれたら良かったのに。なぜかそれでテスト環境も最新だと思ったらしい。一年くらい刷新していないし、自分達もこのバッチのテストや不具合対応していたのに・・・何故わからないのか。
- とにかく情報を整理して理解することが出来ない
ビルドにあたふた
- 結局２２時まで作業して、翌日最新ソースでやり直すことになった。
- 翌日は現地側でのテストのため、午前中は環境が利用できなかった。このあたりの調整も事前にできていない。
- ビルドも少し心配だったので、Google Meetで共有されている作業を覗いてみた。ゾッとした。ビルドのプロジェクト・参照アセンブリなどの理解が浅く、ただビルドするだけに、あたふたしてて全く進んでいない。
- ウィンドウを沢山開いて、あっちこっちいって、ちがうこれじゃない、とか。ひどい状況。
- とりあえずビルドはできたものの、環境が利用できないのでそこでMeetを抜けて放置することにした。あきれてしまった。（因みにこの日、私は体調不良で休暇取得）
送信先が違っていた
- 基幹系とIFする環境には、DB上に接続先が設定されている。
- バッチプログラムだけじゃなく、DB上にはこういった情報やSQLも登録されており、こちらの最新化確認も必要であった。これも伝えてあったのだが・・・
- FTP先がテスト用じゃなく別のリハ用につながっていたそうで、そちらに取り込まれてしまい影響したようであった。
- またもう一つWebサービㇲをつかったれんけいもあるのだが、そちらの接続先についても一年ほど前のままで確認が取れていなかった。
まとめ
- 無計画出迎え、本来の目的からズレた「お茶濁し」テストとした。
- やることなすこと尽く失敗した。
- お客様の費用をつかってこれは許せない。ずっとこんな感じ。自分の段取り不足で、スコープ＆品質を下げて辻褄合わせ。そんな事が許されるのか。
- いつも現場へ丸投げで、私が段取り＆メンバーフォローでなんとか凌いできた。
- 口では偉そうなことを言うリーダーだが、なかなかのポンコツで何も出来ないしやっていない。
不具合がなぜ起きるのか、なにができるのかを考えてみた
投票管理者の合間に考えたこと第二弾です。不具合について考えました。
ざっと
要件（リクエスト）に対し
- OS、プラットフォーム、フレームワーク、ライブラリ、既存部,、データベースなどの理解を経て
- 規約やその他ルール
- これらの上で”どうするか”を考える
- そして実際に作業を行いモノができる
- 出来たモノに対しテストを行い改善していく
不具合の要因・対策
人によって品質が違うのは何故か。そこから考えた。
理解
- インプット及び説明の充実化、サンプルの提示
- 制約
- ルールや定石が該当する。制約があることで選択肢が限定され、考えるべき範囲を限定することができる
- スキル・ノウハウ（経験）
- インプットに対し、自分が持っているものに応じてを使って答えを出していく。
パターン及び作用の把握・見切り
- 整理★
- 工夫
- 気づきやすい工夫
- 見える化であったり、気付ける機会を増やすなど
しかし
気づかない人、考えない人がいる。それら人には外部からのフォロー（フィードバックや教育）が欠かせない。
自分なりのまとめ
考えることを少なくするのがよい。
- 共通化・標準化
- サンプル
- 文書化
- 試せる環境
- 依存の少ない構造（部品化やIF）
- 忘れる
- 忘れても良いようにする（思い出せるように）
- 記録や情報管理
手書きであれこれ考えた
生産管理システム領域について色々考えてみた
参議院議員選挙で投票管理者を午後からやりました。ものすごく暇なので考え事で時間を潰してました。
何を考えてたのか
今後なにを勉強してくべきなんだろう、という疑問がありました。生産管理システム関連の経験が長いので、そこが評価されてプロジェクト参加することが多いです。生産管理といっても、業務領域も技術領域も様々です。思いつくがまま、ブレスト的に手書きしています。最初は最近WEB関係技術の記事をよく見かけますが、WEB経験が少ない・レガシー技術がメインであり、.NET FrameworkでのC/Sシステムだけに知識だけで大丈夫なのかという不安がありました。そのため、C/SとWEBの比較から始まっています・・・
ざっと
- C/SとWEB
- 製造ラインで設備自体を制御するところは流石にC/Sでないと苦しい。
- 監視系、ダッシュボードなどはWEBやBIツールも使われる。見せるだけならBIツールはローコード・ノーコードだし賢くて便利です。
- 自動化、IoTの波
- シミュレーション
- 新製品に製造や段取り（レシピ）をシミュレーション。生産管理の範疇じゃないけれど、ソフトウェアならでのところだと思う。まあ自分の頭では無理だけど。
- 止めない、止まらないシステム
- 予兆監視は重要に思えた。前職でもIoT関連プロダクトの販促で予兆監視のセミナーを開催していた。
まとめ
感じたこと - 自分が関わってきたところは、ほんの一部だと改めて気づいた。 - 製造現場の業務知識、C/Sシステムのテクノロジーや品質に関するところ、そういったところではある程度の活躍できると感じた。 - ソフトウェアテスト、品質保証、開発者（設計やプログラミング）の品質向上 そんなところをもっと学びたい
手書きであれこれ考えた
今従事しているプロジェクトのプログラム設をネタに設計について考える その１
日々少しでもいいから、何か学ぶとか考察するとかしようと考えています。今後の自分を考えた場合、プログラム設計（アーキテクチャというほどのものはない）に関する知識や経験は一定価値があり、これからも大切に育てていかなければいけない。そこで今日は、今日々テストしているシステムのプログラムをネタに設計について考えることにしました。
現行システムのプログラム設計問題点
思いつくがままに挙げてみる
- プログラム間で統一されていない
- モジュール変数が多用されている
- 抽象化や部品化が進んでいない
- 依存が複雑
- コメントが役に立たない
- 構造を示すドキュメントがない
考察
一つずつどういうことか、どうずればいいのか、考えてみる
プログラム間で統一されていない
もう少し具体的に
- 文字通り、パッとよく似た機能でも実装のされ方が結構違っている。レガシーなシステムなので、時期や担当者が違うのかもしれない。
それがどう困るのか
- １つのプログラムを理解しても、その理解が役立てられない。
- 覚えるべき情報量がとても大きくなる。
- その結果、どうしても理解の品質が下がる。
- 単純に疲れるし、頭のキャパを超えてしまう。
どうすればよかった？
- フレームワーク
- 実際にフレームワークを作るのは大変だから、ルールベースでもいいので構造をある程度定めたい
- そのためにも、別途挙げた抽象化や部品化を進めるとやり易くなる。
- アプリのオペレーション仕様をまず整える
- オペレーションが違うものばかりだと、中身を揃えるのも難しくなる。まずはオペレーションから整えたい。
- ちなみにこのシステムは生産ラインでの作業や製造設備に対して設定されるものなので、全体的なオペレーションはよく似ている。実際にいくつかのパターンに分類し処理フローまで用意されちた。そこまで出来ていたので、ルールを作るのは容易だったと思われる。しかし、方針として改修を最低限に抑えるというものがあり、それが結局後々問題を起こすことになる。
- 構造目線設計レビュー、ソースレビューの実施
補足
- ルールがあること、遵守を訴えることは、メンバー育成に一定の効果があると考える
- やはり声を上げ続けることで、メンバーの意識・スキルも上がってくる（伝え方の問題はある）
- ただこの手の押し付けは、受ける側が納得すること、具体的にどうするか想像できることが大切ではないか。伝える側の理解が浅いと、結局”やれっ！やれっ！”だったり、どこかから持ってきたような「効果説明」にとどまり、受ける側は”またか”となるだろう。そうではなく”なるほど、それはいい”と思わせなくてはいけない。そのためにも伝える・指導する側のスキル向上と熱意が欠かせない。
その２へ続く
