2021/11/03(水)GitHub 登録鍵の更新

2021/11/03 14:02 その他::メモ

GitHub 登録鍵の更新


更新のきっかけ

GitHub 公式から、次のような感じのメールを受け取りました。
Hi @kjimba,

We noticed your personal access token "（トークン名）" with notifications and repo scopes will expire in 6 days.

If this token is still needed, visit https://github.com/settings/tokens/669610437/regenerate to generate an equivalent.

If you run into problems, please contact support by visiting https://github.com/contact?tags=dotcom-accounts

Thanks,
The GitHub Team
見た瞬間、新手のフィッシングメールかなにかかと思った……。

本物のようなので、対応します。

更新作業

基本的には、GitHub 公式の手順に従えばいいですね。

案内文にあったリンクから、更新方法のページに移動して、内容を参照します。
https://docs.github.com/ja/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

新しい鍵の作成

鍵生成
新しく登録する鍵を生成します。

以下のメールアドレス name@example.com は、実際には GitHub に登録しているメールアドレスを使っています。
$ ssh-keygen -t ed25519 -C "name@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/jimba/.ssh/id_ed25519):

鍵を置く場所がデフォルトでいいか聞かれたのですが、変更したいので /home/jimba/.ssh/keys/git/id_ed25519 を入力しました。
これは、そもそも私が以前の鍵を置いている場所なので、ディレクトリが存在します。

次に、パスフレーズを聞かれるので入力します。

Enter passphrase (empty for no passphrase): ***
Enter same passphrase again: ***

実際は 3 文字ではないですが……任意のパスフレーズを入力します。

フィンガープリント等が表示されたので、作成できたようです。
念のためファイルを確認します。

jimba ~/.ssh/keys/git $ ll
合計 20
-rw------- 1 jimba pi  419 11月  3 12:21 id_ed25519
-rw-r--r-- 1 jimba pi  104 11月  3 12:21 id_ed25519.pub
-rw------- 1 jimba pi 3434  5月 21 23:39 id_rsa
-rw-r--r-- 1 jimba pi  748  5月 21 23:39 id_rsa.pub
drwxr-xr-x 2 jimba pi 4096 11月  3 12:13 old

きちんとできていました。

id_ed25519.pub は公開鍵なので、GitHub に登録するために中身を確認しておきます。
$ cat id_ed25519.pub
ssh-agent 登録
さて、次に ssh-agent に登録のようです。

$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/keys/git/id_ed25519

これで登録できました。
ssh-agent 確認
確認コマンドは、次の通り。

$ ssh-add -l
256 SHA256:******************** name@example.com (ED25519)

いろいろ伏せてますが、こんな感じで表示されます。
鍵の保管場所を変更していなければ、これで鍵作成の作業は完了だと思います。

私の場合、いままで ssh-agent に登録していなかったので ssh-agent への登録作業はこれで終わりです。
すでに登録しているものがある人は、削除が必要だと思います。

利用する鍵の変更

GitHub 登録鍵の変更
これもいくつか方法がありますが、ブラウザで更新しました。
https://docs.github.com/ja/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account

GitHub へアクセスして、プロフィール画像から Setting へアクセスします。
「SSH and GPG keys」へ移動して「New SSH key」ボタンで、上記で確認した公開鍵の内容をコピペします。
ちなみに、タイトルは自分でわかるものを任意で入力します。

「Add SSH key」ボタンで、入力内容を登録します。パスフレーズの入力画面が出てきたら、入れます。
config 変更
私の場合は、利用する鍵の保管場所がデフォルトではないので、config を変更します。
今回、ssh-agent に登録したので不要になったのかもしれませんが……それはあとで確認 *1 しておきます。
$ cd ~/.ssh
$ [ -d old ] || mkdir old
$ cp -p config old/config_$(date +%Y%m%d)
$ diff config old/config_$(date +%Y%m%d)
$ vi config
(既存の鍵を ~/.ssh/keys/git/id_ed25519 に変更)
$ diff config old/config_$(date +%Y%m%d)
5c5
<       IdentityFile    ~/.ssh/keys/git/id_ed25519
---
>       IdentityFile    ~/.ssh/keys/git/id_rsa

全体を確認すると、次の通り。

$ cat config
ServerAliveInterval 60

Host github github.com
        HostName        github.com
        IdentityFile    ~/.ssh/keys/git/id_ed25519
        User            git

疎通確認

GitHub に正しく設定できているか、テストします。
https://docs.github.com/ja/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection
$ ssh -T git@github.com
Hi kjimba! You've successfully authenticated, but GitHub does not provide shell access.
問題ないようです。

古い鍵の削除

利用しなくなった鍵は自動で削除される *2 っぽいですが、念のため自分で古い公開鍵を削除しておきます。

GitHub へアクセスして、プロフィール画像から Setting へアクセスします。
「SSH and GPG keys」へ移動して、削除したい鍵の「Delete」ボタンで、古い公開鍵が削除できます。

本当に削除してよいのか聞かれるので、削除したい鍵であることを確認の上で「I understand, plase delete this SSH key」ボタンで削除します。

違っていた場合は、×ボタンで閉じればよいです。

*1 : ここでは、行った作業を記録する目的で記載しています。

*2 : SSH キーを 1 年間使っていない場合、セキュリティ上の理由により GitHub は使われていない SSH キーを自動的に削除するとの記載あり。

コメント（0件）

2021/10/27(水)電話系 IPアドレス

2021/10/27 17:59 その他::メモ

電話系通信用 IP アドレス帯域について

スマホなど、電話系の通信を制限（許可or拒否）したいときに利用するので、電話系の IP アドレスは公開されている。
また、どこを参照すればいいのか案内するようなサイトも、いくつも見つかる。
https://www.ipvx.info/2015/02/open_multi_cidr2_merge/

ここでは、その情報と、Whois gateway での探し方をまとめている。


nttdocomo

公開範囲

企業が、ユーザのネットワーク通信用に使用していると公開している IP アドレス範囲。
https://www.nttdocomo.co.jp/service/developer/smart_phone/spmode/

取得範囲

企業が取得している IP アドレスの範囲。
（Whois gateway での検索ワード）
http://whois.nic.ad.jp/cgi-bin/whois_gw
項目ワード
ネットワーク情報(組織名、Organization)NTT DOCOMO,INC.

KDDI

公開範囲

企業が、ユーザのネットワーク通信用に使用していると公開している IP アドレス範囲。
EZweb端末用
https://www.au.com/ezfactory/tec/spec/ezsava_ip.html
2011秋冬モデル以降
NoIPアドレスサブネットマスク (bit)備考
127.90.207.224/28
227.90.207.240/28
327.90.220.224/28
427.90.220.240/28
2019年12月5日時点
上記以外の EZweb端末
NoIPアドレスサブネットマスク (bit)備考
127.80.181.240/28
1827.90.206.0/26
1927.90.206.64/26
2027.90.206.128/26
2127.90.207.0/26
2227.90.207.64/26
2327.90.207.128/26
2427.90.220.112/28
スマートフォン/タブレット/4G LTE ケータイ
[au.com/developer/android/kaihatsu/network/]
NoIPアドレスサブネットマスク (bit)備考
1106.128.0.0/13106.135.0.0/16 を除く
2106.180.16.0/20
3106.180.32.0/20
4106.180.48.0/22
5111.86.140.128/27
6182.248.112.128/26
7182.249.0.0/16
8182.250.0.0/15
92001:268:9000::/36
102001:268:9800::/40
112001:268:9900::/40
122001:268:9a00::/40
132001:268:9b00::/40
2021年10月時点

取得範囲

企業が取得している IP アドレスの範囲。
（Whois gateway での検索ワード）
http://whois.nic.ad.jp/cgi-bin/whois_gw
項目ワード備考
ネットワーク情報(組織名、Organization)KDDI CORPORATION範囲が広すぎるとのこと

Softbank

公開範囲

企業が、ユーザのネットワーク通信用に使用していると公開している IP アドレス範囲。
スマートフォン/タブレット/4G LTE ケータイ
https://www.support.softbankmobile.co.jp/partner/home_tech1/index.cfm
NoIPアドレス/CIDR備考
1126.32.80.0/21
2126.32.89.0/27
3126.32.89.128/27
4126.32.90.0/23
5126.32.92.0/23
6126.34.0.0/18
7126.34.96.0/19
8126.133.192.0/18
9126.156.128.0/17
10126.157.64.0/18
11126.157.192.0/18
12126.158.128.0/17
13126.161.0.0/18
14126.161.64.0/21
15126.161.80.0/21
16126.161.96.0/22
17126.161.104.0/22
18126.161.116.0/22
19126.161.124.0/22
20126.166.128.0/17
21126.167.64.0/18
22126.179.0.0/18
23126.179.96.0/19
24126.179.128.0/18
25126.179.224.0/19
26126.186.32.0/19
27126.186.96.0/19
28126.193.128.0/18
29126.193.208.0/21
30126.193.216.0/22
31126.194.64.0/18
32126.194.192.0/18
33126.200.0.0/18
34126.200.112.0/20
35126.204.0.0/18
36126.204.64.0/21
37126.204.88.0/21
38126.204.96.0/19
39126.204.128.0/19
40126.204.176.0/21
41126.204.216.0/21
42126.204.224.0/19
43126.205.192.0/18
44126.208.128.0/17
45126.211.0.0/18
46126.211.112.0/20
47126.212.0.0/19
48126.212.80.0/21
49126.212.128.0/18
50126.212.240.0/20
51126.234.0.0/18
52126.234.96.0/19
53126.236.128.0/18
54126.237.0.0/18
55126.237.64.0/21
56126.237.80.0/21
57126.237.96.0/22
58126.237.104.0/22
59126.237.116.0/22
60126.237.124.0/22
61126.253.128.0/17
62126.254.128.0/17
63126.255.0.0/17
64126.255.128.0/18
2021年07月16日時点（集約済み）

取得範囲

企業が取得している IP アドレスの範囲。
（Whois gateway での検索ワード）
http://whois.nic.ad.jp/cgi-bin/whois_gw
項目ワード備考
ネットワーク情報(組織名、Organization)不明
APNIC WHOIS(whois.apnic.net) / ARIN WHOIS(whois.arin.net) / RIPE WHOIS(whois.ripe.net) / LACNIC WHOIS(whois.lacnic.net) / AfriNIC WHOIS(whois.afrinic.net) の Whois サーバに登録が無い模様。
コメント（0件）

windows の資格情報削除

2021/10/02 17:10 その他::メモその他::技術情報

Windows の資格情報削除

Windows を利用していると Teams のログインなどで登録されることがあるアカウント情報。
消すならWinキー→資格といれて資格情報にアクセス

資格情報マネージャーへのアクセス方法

サーチ利用
Win キーから「資格」と入力した状態で、資格情報マネージャーにアクセスできる。
資格情報マネージャー
資格情報マネージャー

ちなみに、英語で Credential Manager らしく、cred を入力してもアクセス可能。
Credential Manager
Credential Manager

アカウント情報削除

アカウントへのアクセス
「Web 資格情報」と「Windows 資格情報」があるが、Teams で利用するアカウントは Windows 資格情報の中にある。
Web資格情報
Web資格情報
Windows資格情報
Windows資格情報
情報削除
Windows 資格情報のなかで、汎用資格情報のなかに「SSO_POP_User:user=xxx@example.co.jp」のような内容があるので、それを開く。
SSO_POP_User
資格情報の例
この「削除」をクリックすると、次の削除確認がポップアップする。
削除確認
削除確認
ここで「はい」を選択すれば、資格情報が削除される。
コメント（0件）

IT系エンジニア

2021/10/25 18:02 その他::メモ

エンジニア系


IT 系エンジニアがどのような職種なのか、簡単に説明する資料を作ってみました。

インフラエンジニアから見る IT 業界
インフラエンジニアから見る IT 業界

以下で、それぞれの枠について説明したいと思います。

システム開発

システムエンジニアを大雑把にいえば、システムの組み合わせと調整を主に行います。
小さな運用スクリプトやマクロ等は作ることがありますが、大規模なアプリケーション開発は行いません*1。

システム開発において「要件定義」「設計」「構築」「検証」といったフェーズで、それぞれの成果物を要求されます。

要件定義は、お客様から聞いた内容を要件として整理するフェーズです。
どんな要求があり、何を使って解決するのか、システムの大枠を整理します。
プロジェクトによっては、コンサルタントが既に済ませていることもあります。
アウトプットとして、要件定義書が求められます。

設計は、要件定義を具体的に落とし込むフェーズです。
細かい設定値はさておいて、要件に沿った方針を決める基本設計と、基本設計をもとに設定値に落とし込む詳細設計に分けることが多いです。
アウトプットとしては設計書（基本設計書/詳細設計書）になるのですが、実際に構築するための作業手順書が含められることも多いです。

構築は、設計値を元に、実際にシステムをくみ上げていくフェーズです。
作業手順書をもとに作業するため、アウトプットとして、いつ、手順書のどこを、どのように実行したかを示すエビデンスと、第三者が設定値を検証可能なエビデンスを求められます。
よく利用されるのは、ツーマンセルで一人が実行役、一人が記録役になります。記録役が、印刷された手順書に実行時刻を記載することが多い *2 です。

専用のアプリを作るまでもない、運用のためのスクリプトを作ることもあります。
最低限、フローチャートは読めないと困るでしょう。

システムで利用する機器とそれに付属する OS /専用アプリはもちろん、アプライアンス（システム用の製品）関係の知識も必要です。

非常に幅広い知識と応用力などが要求されます。

なお、システムエンジニアは基本的にプレイヤーなので、マネジメントも行うようになるとマネジメントプレイヤーもしくは何でも屋という名称で呼ばれたりします。
インフラエンジニア
システムエンジニア内でも専門性があり、次のように分かれます。
サーバエンジニア
コンピュータでサービスを動かし、システムに必要なサーバを提供するのが主な仕事になります。

サーバの物理的なスペックから載せる OS についての知識、サービス用のアプリケーションインストール、状況に拠ってはチューニングといった仕事を行います。

サーバには UNIX や Linux といった POSIX 準拠の OS 上で動くものや、Windows で動くものなどがあります。
Linux しか触れない、Windows しか触れないといったエンジニアもいます。

POSIX で共通仕様は決められていてもベンダーごとに特徴はあるので、HP-UX は使えても Solaris は分からないといったことはあり得ます。
ネットワークエンジニア
ネットワークケーブルを敷設し、お客様とサーバが円滑に通信できるネットワークを提供するのが主な仕事になります。
実績と信頼性の高さから、商業用には主に Cisco 製品の知識が求められます。
普段は bps (bit per sec) の単位でネットワークを見ているので、Byte 単位が基本のアプリ側とやり取りするときは変換が必須です。
データベースエンジニア
システムが利用する情報を整理し、適切に応答するデータベースを提供するのが主な仕事になります。
商業用には主に Oracle 製品の知識があると良いでしょう*3。

OSS としては mariaDB が採用されることも多いです。
SQL という、DB 向けの言語であってもアプリ毎の設計方針から方言の癖がつよいので、この DB しか使えないという DB エンジニアもいます。
セキュリティエンジニア
システムに含まれる脆弱性と、無数のアタッカーからシステムを守るシステムを提供するのが主な仕事になります。
ネットワーク、OS、アプリそれぞれのセキュリティ情報や、防御用アプライアンスの知識などが求められます。
ソフトウェアエンジニア
ソフトウェエンジニアもシステムエンジニアに数えられますが、ここでは割愛して別項目にします。
ウェブエンジニア(未掲載)
ウェブエンジニアもシステムエンジニアに数えられます。
ただし、ウェブ上で利用されるシステムという、分かるような分からないような曖昧な定義になっています。

共通するのは、WebUI *4 をもつシステムに携わるというところです。

WebUI のデザインを行っているかと思えばネットワークのボトルネックを調べていたり、アプリケーション開発をしていたり、サーバのチューニングをしていたりします。

扱う範囲が広すぎるので、お客様が直接扱うソフトウェア側をフロントエンド、フロントエンドを構成するためのインフラ側をバックエンドと呼ぶようです。

上の図には未掲載です。
フロントエンドエンジニア
ブラウザで直接操作するアプリと、その UI を主に扱うエンジニアを、フロントエンドエンジニアと呼びます。
お客様の前に立つ、ホテルのフロントをイメージすると理解しやすいかもしれません。

HTML / CSS / XML / JSON といった、ブラウザで直接扱うマークアップ言語や、そのコードを出力するためのアプリケーションに Java / Ruby / PHP といったスクリプト（インタプリタ型言語）が使われています。

まれに、高速な応答が必要なシステムで C 言語といったコンパイラ言語（コンパイル型言語）が使われることもあるようです。

担当する業務によっては、ネットワークを意識することがないとか、他にもウェブデザイナー業務を担当することがあると聞いています。

バックエンドエンジニア
ブラウザ操作で意識しない、裏方のシステムを主に扱うエンジニアを、バックエンドエンジニアと呼びます。

インフラエンジニアと業務内容が被るのですが、インフラエンジニアはウェブ操作とは全く関係ないシステムも扱うため、微妙な差異で使い分けられています。
クラウドエンジニア(未掲載)
IaaS を中心としたサービスを主に扱うシステムエンジニアです。

コーポレートエンジニア

どちらかというと発注側のエンジニアで、社内システムに特化しているのがコーポレートエンジニアです。
社内エンジニアとも呼ばれます。

外注のために浅くても広い知識や、査収といった業務を行います。
このため、会社の業務知識だったり、他社への発注手続きだったりと、庶務系に比重が置かれることも多くなります。

また、次のツイートが参考になると思います。
言及のある、タスクディクショナリは、こちら。
https://icd.ipa.go.jp/icd/icd

コンサルタント

コンサルタントは、経営者やプロジェクトの責任者などが抱える課題について、アドバイスやソリューションを提供するのが主な仕事になります。
コンサルタントも専門で分かれるのですが、システムエンジニアからすると上流の仕事になります。

提案書を求められることがあります。
プリセールスエンジニア
プリセールスエンジニアはインフラエンジニアのなかでも営業に近く、システムの知識を持ちつつ、知識を生かした提案や、経営課題のソリューションを提供するのが主な仕事になります。
システムを見ながら、コンサルティングできるエンジニアです。
提案力（プレゼン能力）やコミュニケーションといった、政治力が強く求められます。

ワーカー

出来上がっている手順書の通りに、システムを構築したり検証したりといった作業を行います。
設計がおかしければ指摘したりする必要はありますが、基本的には事前にやることが決まっています。
そのため、エンジニアとは呼ばれません。

組込エンジニア

システムとしては少し毛色が変わりますが、組み込みエンジニアもエンジニアです。
サービスが動くのではなく、マイコンなどのデバイスで動くシステムを作ります。

どちらかというと、デバイスを制御するためのシステムですね。
ハードウェアの知識が必要になるため、デバイスの開発を行うこともあるようです。

コンピュータを内蔵する機械であれば組込システムが存在するため、目立ちませんが必要な役割です。
デバイス
組込エンジニアでも、身近な製品（デバイス）を開発するのがメインのエンジニアです。

IC やら抵抗やら、基盤設計を行う人がいると思えば、出来上がった基盤を制御するソフトウェア開発を行う人もいます。
もちろん、全部面倒みる人もいます。

マイコン（マイクロコンピュータ）や、組込 Linux もあって、外部からはかなり混沌とした業界のように見えます。
制御ソフト
ミシンや自動車といった身近なものから、工業ロボットのような大型の機械を制御するソフトウェア開発も、組込エンジニアのようです。

*1 : アプリケーション開発は、ソフトウェアエンジニアの仕事です。

*2 : PCでの時間入力は、改ざんが容易なため敬遠される傾向があります。

*3 : これを書いている時点では Oracle 社の経営方針に嫌気がさし、OSS に移行するユーザも増えています。

*4 : WebUI は、ウェブブラウザによりユーザがシステムを操作するインターフェースのこと。

ステークホルダー

アプリ開発

ここでは、システムエンジニア視点でのステークホルダーとしてくくっています。
デベロッパ
開発する人たちの総称です。

BIND、Apache/nginx、Sendmail、Samba、Docker/CRI-Oなどサーバとして動かすアプリを開発する人たちが含まれます。
彼らがいなければ、システムエンジニアは成り立ちません。

アプリに対する深い理解が必要不可欠です。
アプライアンス
特定目的のアプリを、想定されるユースケースにおいて使いやすいシステムで提供するベンダーです。

条件によっては採用するほうがコストが安く品質を上げられるため、彼らが世に出す製品は広く知っておくべきです。
あまり詳細を知れないので、雲の向こう側として表現しています。
その他
ソフトウェアエンジニアという呼称が存在する、立派なエンジニアです。
こちらもシステム開発動揺、要件定義、設計、コーディング、検証といった流れが存在します。
Web アプリを開発するなら、Web エンジニアと呼ばれたりするようです。

書いている人がソフトウェアエンジニアではないので外から眺めた感じの表現になってしまいますが、概ね間違っていないと思います。
ソフトウェアエンジニア
要件定義から検証まで、一貫して行えるアプリケーション開発者がソフトウェアエンジニアだと考えています。
プログラマ
要件定義の済んでいるアプリケーションを、設計から行うのがプログラマだと考えています。
コーダ
コーダは設計済みのフローチャート通りにコーディングする人のことだと考えています。
システムエンジニアにおけるワーカーのようなものですね。
テスタ
開発の済んだコードが、要件を満たす挙動をするかどうか試験するのがテスタだと考えています。
デバッガ
ほぼほぼテスタなのですが、開発の済んだコードの検証に加えて、開発者の想定外の挙動までチェックするのがデバッガのイメージです。

運用・保守

システムを作っても、それを維持したり、状況の変化に応じてメンテナンスしたりしなければ、動かないシステムになってしまいます。
基本的には想定される状況がすべて網羅された手順書があり、就職先としてのハードルは低いです。

問題が起きたら即座に対応しなければならないサービスの場合、システムエンジニアが兼任することもあります。
ヘルプデスク
クライアントの設定から故障対応まで、ユーザが操作するコンピュータを責任範囲とします。
理不尽が多いのも特徴です。
オペレータ
運用（オペレーション）を行います。

運用とは、たとえばユーザアカウントの追加や定期的な稼働確認といった内容になります。
24時間365日、システム監視ツールが動き、問題を検出したら状況確認から対応することになります。

対応は、関係部署への連絡です。

手順書はありますが、簡単に障害箇所を切り分ける能力が、ある程度求められます。

サーバが不通であればシステムエンジニアへ連絡。
ネットワークに問題があれば、ネットワークエンジニアに連絡。
物理機器が故障しているようであれば、保守員へ連絡。

そういった連絡が主な仕事です。
ただし、切り分けの結果によってはその場で対応しなければならないことも多く、運用と保守はひとまとめにされることも多いです。
保守員
保守（メンテナンス）を行います。
勤務時間は保守契約により日中対応だけのものから、24時間対応のものもあります。

保守とは機械が壊れたときに交換するといった内容になります。
基本的には連絡待ちになりますが、初期稼働を早めるためにシステム監視を行うことがあります。

内容的に運用と被るものが多いので、運用と保守はひとまとめにされやすいです。

管理

プロジェクトやプレイヤーのマネジメントを行う人たちです。
PM
PM はプロジェクトマネージャーの略で、プロジェクトを管理します。
管理とは、予定をたてたり、進捗状況をみてテコ入れをしたり、お客様と交渉したり、成果物を見て改善を指示したりといった内容です。
進捗管理や品質管理といった呼称が使われます。
PMO
PMO はプロジェクトマネジメントオフィスの略で、PM が担当するプロジェクトをチームとして支援します。

PM は一人ですが、PMO は複数人でプロジェクトにあたります。
大規模な開発では一人で進行を管理しきれないため、必要となります。
PL
PM の立てた計画を遂行する立場です。

場合によってはシステムエンジニアが兼任することもありますし、システムエンジニアに PL の能力を求める人もいますが、基本的に PL はマネジメント側になります。

発注

ビジネスオーナー
ここでは、プロジェクトを定義して、システムを発注するのがビジネスオーナーであると定義しています。
システムエンジニアが直接話す機会は少なく、雲の上の存在となっています。
コメント（0件）