れんとう

まいにち なにか ひとつ

オレオレリポジトリとlftpコマンド

オレだよオレオレ!

実家にオレオレ詐欺の電話があったらしい。

  1. 風邪ひいてるから声がいつもと違う
  2. 電話は友達のを借りた
  3. 上司と喧嘩して会社辞めることになった
  4. とにかく至急お金が欲しい

とのたまわったとか。

ちなみに、両親は、3で本気にしたようだ!

俺のことどんなキャラだと思ってんだよ!

ローカルに作ったリポジトリ、名付けて、「オレオレリポジトリ

VM、PMを合わせると、ScientificLinuxで3台、OpenBSDは2台、Windowsは…4台。

さらに、RaspberryPiについても4枚転がっているわけで。

これらが一気にアップデートでネット接続すると、ネット回線が混雑するんだよね。

時間帯をずらしたりもしたんだけど、同じデータをDLするのにトラフィック発生ももったいないな、と思ったもので、ローカルにリポジトリを作ることにした。

というか、作った。

それを「オレオレリポジトリ」と名付けている。

かれこれ3年くらい、快適に使ってる。

「オレオレリポジトリの作り方」

WindowsのWSUSもローカルに作りたいのだが、今はフリーではないようだ。

なので、まずは、Linuxなどのリポジトリをローカルに作った。

yumコマンドやaptコマンドはネット上に公開されているリポジトリのhttpやftpサイトを見に行ってるわけだから、ローカルに同じ構造のものを作ってしまえばよい。

その後、各クライアントの参照先をローカルに向ける。

サーバの構築手順はこんな感じ。

なので、とても簡単。大きなサイズのディスクがあればよい。

クライアントについては、/etc/yum.repos.d 以下の$baseと$URLをローカルに構築した先に向けて、書き換えればO.K.。

 

lftpコマンドのスクリプトもこんな感じ。

下記は、ScientificLinux7.3をとある公開ミラーから丸ごとDLする場合の例。

 

!/bin/bash
lftp -e 'mirror --delete --only-newer /pub/Linux/scientific/7.3/ /var/www/html/local/scientificlinux/7.3/ && exit' http://www.hogehoge.jp

 

www.hogehoge.jp/pub/Linux/scientific/7.3をローカルの/var/www/html/local/scientificlinux7.3にダウンロードしてる。

lftpコマンドは、ローカルとサーバーのミラーに用いられる。

--only-newerの指定で、ローカルとサーバーの比較をして、更新されたものだけ落としてくれるので、トラフィックにも負荷をかけない。

--deleteの指定で、サーバーで削除されているファイルはローカルでも削除される。

 

で、だ、快適にすごいていたのに、ある日気がついた。

あれ?7.3のDLなんか止まってない?

ゾンビってる

cronでDLスクリプト実行の開始前と開始後に

date >> ~/cron-update.log

を挟んで、実行時間がどのくらいかかるか参考にしているのだが、ログファイルを見て、気がついた。あれ?アップデートスクリプト、完了してなくない?

psコマンドで確認すると、ゾンビってる。

あれ、なんでだろ?夜間に自動実行してるから、気がつかなかった。なんでだろ?

ということで、手動実行してみた。

 

# lftp -e 'mirror --delete --only-newer /pub/Linux/scientific/7.3/ /var/www/html/local/scientificlinux/7.3/ && exit' http://www.hogehoge.jp

cd 成功、cwd=/                                                

x86_64/release-notes: Getting files information (100%) [応答を待っています...

 

x86_64/release-notes というディレクトリのDLでどうやら引っかかっているようだ。

ブラウザで確認するとただのhtmlファイルなのでが、なぜか引っかかる。

逆に、ここはアップデートとはあまり関係ないところだ。

ちなみに、wgetコマンドで落とせたので、ここはwgetで対応すればいいや。

よし、x86_64/relese-notesを除けばいいのだな。でもどうやるんだろ?

 

-xオプションで解決だ!

man lftpしたら、マニュアル入ってなかったので、公式サイトを見に行ってみた。

LFTP - sophisticated file transfer program

PDF版のマニュアルゲット!

それを見ると、-xオプションについて書かれていた。

 

−x RX, −−exclude=RX exclude matching files

 

-xオプションでマッチングするファイルやディレクトリを除外できるようだ。

release-notesというフォルダは、他にないようなので、除外するようにスクリプトを直してみた。

 

#!/bin/bash
lftp -e 'mirror -x release-notes --delete --only-newer /pub/Linux/scientific/7.3/ /var/www/html/local/scientificlinux/7.3/ && exit' http://www.hogehoge.jp

 

実際に実行してみたら、うまくいった!

やったぜ!

 

rsyncとの違いは?

ローカルにオレオレリポジトリを作るときにrsyncコマンドも用いられることがあるようだ。どう違うのだろうとちょっとググってみた。

rsyncは、常時、サーバー間のファイルを比較して同期をとる用途のときにもちいるとよさそうだ。というかそういう用途向けらしい。

俺のオレオレリポジトリは、そこまで細かく同期をとるつもりもないので、週1くらいでDLすればいい。そういう時はlftpの方がいいみたい。

 

ということで、無事、オレオレリポジトリ、定期的に最新版に更新されるようになったよ!

WSUSも作っておきたいな。

 

乗り換えるならVisual Stdio Code

エディタなに使う?

WindowsOS XLinuxと複数の環境を使う身としては、環境ごとに違うエディタを使うのは、めんどくさい。できれば、統一したいな?と思うわけ。

で、だ。

ならなに使う?

viとかemacsならどの環境でも存在するけどさ、それもちょっとな、と思うわけ。

で、今時なら、AtomかVisual Stdio Codeかなと思うわけ。

 

Atom

Visual Studio Code - Visual Studio

 

悩んだ末、Visual Studio Codeにした。

まだ使い込んでないからわからないけど、さ。

最近のMicosoft製品って好きだしね。

それに、VisualStdioの他のエディタと共通点多いんじゃないかと思ったのでね。

ということで、あちこちの環境にインストールしているのです。

Linuxで使うには?

いろんなインストール方法があるみたいだけど、リポジトリを使って簡単にインストールすることにした。

ちなみに、openSUSEへのインストールはこんな感じ。

$ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
$ sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ntype=rpm-md\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/zypp/repos.d/vscode.repo'
$ sudo zypper refresh
$ sudo zypper install code

インストールが終わったら、コンソールから

code
と入力したら簡単に使える。
 
使ってみるとこんな感じ。
 

f:id:dawon2015:20180112000351j:plain

複数バッファの編集、デバッグコンソールやターミナルが一体化した環境。

うん、昔(ちょっとだけ)使ってたemacsに似てるね。

収斂進化ってこういうことだろうなぁ。

 

おまけ

ちなみに、サンプルプログラムはここから。

f:id:dawon2015:20180112001456j:plain

 

ブックオフで300円で購入。

え?古すぎるって?

いやいや、いいんですよ、これが。

昔の本って、アーキテクチャからちゃんと書かれていて、ほんと勉強になる。

最近の本って、盛り込むことが多いから、基礎のアーキテクチャの部分って省略されちゃうんだよね。

まずは、その、省略されている部分の記憶を呼び戻して、復習するところから始めるぞ!

 

openSUSE Leap42.3の解像度ってどうやって変えるの?

せまい

f:id:dawon2015:20180111005043j:plain

 

VMWareFusionにopenSUSE Leap 42.3を突っ込んでみた。

openSUSEのデフォルトのこの壁紙は、とても素敵だといつも思う。

が、画面がせまい!これ、解像度800x600かな?

で、設定を直そうと思ったんだけど…。

恥ずかしながら、最近のLinuxのXの設定ってよく知らない。

 

結局どこに?

f:id:dawon2015:20180111003448j:plain

 

「アプリケーションメニュー」ー「設定」ー「KDEシステム設定」

を選択。

 

f:id:dawon2015:20180111003510j:plain

 

「ディスプレイとモニタ」を選択。

ここ、画面のした〜の方にあるので、見つけるまでが大変でほげった。

 

f:id:dawon2015:20180111003908j:plain

 

あとは、解像度直すだけ。

 

かっこよくなりたい

Xの設定とかゴリゴリと書けるようならかっこいいのですけどね。

今回はGUIに頼りました。

openSUSEはデスクトップ環境としていろいろ使ってみたいところ。

 

俺の夢!WindowsからUNIXへのシームレスな接続なるか!? 〜WSLのインストール〜

かつて、仕事柄、UNIXを扱う方が多かった。
TeraTermはお友達。SSHになってからはPuTTYに乗り換え。
なので、シームレスにUNIXに接続できる環境をクライアントに作ることになる。
Cygnus(Cygwinになる前)とMIXをWindowsNTに突っ込んで、rxvtからサーバーにつないでX Windows転送をローカルへなんて、あーでもないこーでもないとやっていたのは、もう、ずいぶん昔のことになるな。
VMWarePlayerが実用的になってからは、そこにLinux突っ込んでクライアントにしてたけど、そのため「だけ」にわざわざVMを用意するのもなぁと思ってたんだよね。

もっと、シームレスにUNIXに接続できる環境を!Windowsで!とずっと思っていた。
うん、ついに、真打登場したらしい。

Windows Subsystem for Linux(WSL) 登場

そんな中で登場したのが、Windows Sybsystem for Linux、略してWSL。
前からβ版で提供されていたけれど、「Windows 10 Fall Creators Update」から正式版になった。
Linux互換のカーネルインターフェースの上でLinuxのソフトウェアを動かすという形LのLinux環境で、ストアアプリとして提供される。
この互換カーネルは、Linuxカーネルのコードは含んでいないらしく、あくまでも「互換」。なので、互換カーネルが提供していないサービスコールを呼び出すソフトウェアは動かないらしい。だが、そんな特殊なソフトウェアは、パッと思いつかない。うん、つまり、自分で使う分には十分に実用的だろうな、と思った。

ということで、導入してみることにした。

 

Windows10のアップデートから


WSLを使用するためには、「Windows 10 Fall Creators Update」の適用が必要になるので、WindowsUpdateを忘れずに。

「開発者モード」の設定と「Windowsの機能の有効化または無効化」
あちこちの記事を読むと「Fall Creators Updateの適用後は、開発者モードでなくてもWSLが使える」というようなこと見かけるけど、うちの環境では、開発者モードをオンにしないとインストールできなかった。どっちにせよ、開発者モードで使って問題ないので深く考えずにオンにする←謎理論一歩前のダメ発言。
この章は飛ばし読みして、うまく起動しなかったら、戻ってくるといいと思うよ?

 

まずは、「開発者モード」の設定から。

 

f:id:dawon2015:20180107210954j:plain

「設定」ー「更新とセキュリティ」を選択。

 

f:id:dawon2015:20180107211049j:plain

①最新状態=Fall Creators Upate」であることはチラ見する。
②「開発者向け」をクリック。

 

f:id:dawon2015:20180107211129j:plain

「開発者モード」にチェックがついてなかったら、チェックしよう。

 

f:id:dawon2015:20180107211155j:plain

なんか脅迫されるが、黙って、「はい」。

 

f:id:dawon2015:20180107211221j:plain

有効になると、「開発者モード」にチェックがつく。

 

次は、「Windowsの機能の有効化または無効化」でWSLを有効にする。

 

f:id:dawon2015:20180107211404j:plain

「設定」ー「アプリ」を選択。

 

f:id:dawon2015:20180107211430j:plain

下の方にスクロールしていくと、「関連設定 プログラムと機能」があるので、クリックする。

 

f:id:dawon2015:20180107211502j:plain

Windowsの機能の有効化または無効化」をクリックする。

 

f:id:dawon2015:20180107211521j:plain

Windows Subsystem for Linux」にチェックを入れる。

 

f:id:dawon2015:20180107211554j:plain

これで作業完了!再起動したら、いよいよ、WSLをイストールするよ!

 

アプリストアからダウンロード

 

インストールは、「ストア」からダウンロードするだけ。

 

f:id:dawon2015:20180107211637j:plain

まずは、ストアを起動する。検索ボックスに「Linux」と入力すると、「WindowsLinux を実行する」という文字が見えるね。
そこをダブルクリックしてみる。

 

f:id:dawon2015:20180107211716j:plain

インストールできるディストリビューションが出てくる。
このインストール作業をしたのは、2017.12.09、今確認した(2018.01.07)けど、変わらないね。
UbuntuopenSUSE Leap42、SUSE Linux Enterprise Serverの3つ。
Fedoraは謳い文句に名前はあるものの、リストにはのって来ないね。
今回は、openSUSE Leapを選択してみる。なぜかって?openSUSE LeapはVM切って普段使いしてるから親しみがあるの。RedHat系だから馴染みがあるしね(YaSTとかちょっと特殊ではあるけど)。
ディストリビューションごとのウンチクは、また後ほど。

 

f:id:dawon2015:20180107211810j:plain

「入手」をクリックでインストールは簡単に始まる。
あとは、待つだけ。

待ってる間に、せっかくだから、説明文でも訳してみますかね。

 

f:id:dawon2015:20180107211832j:plain

openSUSEは、安定していて、簡単に使えて、全ての用途に適したLinuxディストリビューションである。

openSUSE 42を起動するには、コマンドラインから"opensuse-42"と入力するか、Windows10のスタートメニューからopenSUSE42のタイルをクリックする。

ユーザーと開発者がデスクトップまたはサーバーで使用すること意図している。それは、ビギナー、経験のあるユーザー、スーパーハカーにとって素晴らしいことだ!一言でまとめると、完璧!だ!最新リリースであるopenSUSE Leap 42.2の特徴は、大量の便利なサーバーアプリケーションとユーザーアプリケーションが改良されて、新しくなったことだ。1,000以上のオープンソースアプリケーションが含まれている。

openSUSEもまた、SUSE Linux Enterprise製品をベースにしている。openSUSE Leap 42.1はSLE(SUSE Linux Enterprise)をベースにしており、Leap 42.2のソースコードの多くは、SLE 12のサービスパック2をベースにしている。NVIDIMM、OmniPATH、OpenVSwitch(Data Plane Development Kit)のような新しいテクノロジーはバックポートされている。XENはもはや専用のカーネルを必要とし、デフォルトカーネルでサポートされている。SLEのコードベースであるため、openSUSE Leap 42.2はパッケージ、メンテナンス、バグフィックスも、openSUSEコミュニティとSUSEのエンジニアが協力している。
leap42シリーズは、42.1のリリースから、少なくとも36ヶ月のメンテナンスとセキュリティアップデートを提供を達成している。

より多くのことを学びたければ

https://www.opensuse.org/

コミュニティのサポートは

https://forums.opensuse.org/forumdisplay.php/667-Get-Technical-Help-Here

ちなみに、和訳の正確度については保証しません!(雰囲気はなんとなく掴めてるはず)

さて、インストールが終わったら起動するよ!

WSLの起動と設定

さてさて。
和訳した通り、コマンドラインかタイルから、WSLは簡単に起動できる。
ので、やってみた。

f:id:dawon2015:20180107212240j:plain

初回起動時には、
①使用するユーザー名とパスワード
②rootのパスワード
の入力が求められる。
それが終われば、あとは、Linuxコマンドプロンプトだ。

ユーザーに関しては、Windowsのユーザーをそのまま使うのでなく、WLSの内部で別管理になるようだ。

ちなみに、サンプル画面では、ユーザー名をnagaにしてパスワードも同じnagaにしたら、「違う文字にしろ!」と怒られてる。

画面が小さいなと思ったら、タイトルバーを右クリックして、プロパティから、フォントサイズやウィンドウサイズを直せるので、適宜設定すると見やすくなるね。

さてなにをしよう

Microsoftの公式サイトをいくつか眺めてみた。

blogs.msdn.microsoft.com

channel9.msdn.com

 

Windowsしか知らない人にUNIXの裾野を広げる」という意図がはっきりみてとれる。
かつて、MicrosoftUNIXを目の敵にしていた時代を思うと、変わったな、と思うね。

さて、インストールしただけじゃなくて、何かしてみたい。
なにをしようかな?

ssh-keygenについて調べてみた 〜鍵束の話の続き〜

フォーマットの違いはわかったけれど

ちょっと前のエントリにも書いた、鍵束の違いについて。

dawon2015.hatenablog.jp

なんか、自分のログを調べたら、こんなメモ書きが出たきた。

ーーーーーーーーーーーーーー
puttygenとssh-keygen -i -f key.pub >> authorized_keys

OS Xならば普通にssh-keygenコマンドで公開鍵と秘密鍵を作ればいい。

中身がBSDだから、当たり前と言えば、当たり前。

Windowsではどうする?

puttygenで秘密鍵と公開鍵を作って、公開鍵をホストへ転送。

その後、ホストで、

ssh-keygen -i -f key.pub >> authorized_keys

して、鍵束に突っ込んでやる。

cat kye.pub >> authorized_keys

だと、うまくいかない。ファイルフォーマットが違うようだ。

ーーーーーーーーーーーーーー

どうやら、3年くらい前に、同じことをやって悩んでいたようだ。

なるほどねぇ。だから、サーバーAには、OpenSSH形式とSECSH形式の両方の公開鍵が登録されていたわけだ。

たまには、真面目に、manを読む

ssh-keygenコマンドは、鍵の発行だけでなくフォーマットの変換もしてくれる、ということはメモ書きを読んでわかった。

しかし、なんも注釈がないメモ書きであるところを見ると、多分、Google大先生に、「Windows ssh-keygen」でお伺いを立てたのだろうなと、思われる。

うん、ここは、ひとつ、いい機会だから、勉強してみよう、と思った。

UNIXのよいところは、「質の良い豊富なドキュメントがコミュニティによって整備されている」ことでもあるのだけど、意外と活用できてないよね。

ということで、やってみた。

$ man ssh-keygen

 

SSH-KEYGEN(1)             BSD General Commands Manual            SSH-KEYGEN(1)

 

NAME

     ssh-keygen — authentication key generation, management and conversion

 

SYNOPSIS

     ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa | rsa1]

                [-N new_passphrase] [-C comment] [-f output_keyfile]

     ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

     ssh-keygen -i [-m key_format] [-f input_keyfile]

     ssh-keygen -e [-m key_format] [-f input_keyfile]

     ssh-keygen -y [-f input_keyfile]

     ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]

     ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]

     ssh-keygen -B [-f input_keyfile]

     ssh-keygen -D pkcs11

     ssh-keygen -F hostname [-f known_hosts_file] [-l]

     ssh-keygen -H [-f known_hosts_file]

     ssh-keygen -R hostname [-f known_hosts_file]

     ssh-keygen -r hostname [-f input_keyfile] [-g]

     ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]

     ssh-keygen -T output_file -f input_file [-v] [-a rounds] [-J num_lines]

                [-j start_line] [-K checkpt] [-W generator]

     ssh-keygen -s ca_key -I certificate_identity [-h] [-n principals]

                [-O option] [-V validity_interval] [-z serial_number] file ...

     ssh-keygen -L [-f input_keyfile]

     ssh-keygen -A

     ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]

                file ...

     ssh-keygen -Q -f krl_file file ...

書き出しが、「ssh-keygen 認証鍵の作成、管理、変換」。

ここから察するに、-i -m -f あたりオプションをみていくと良さそうだ。

-i オプションにはなんと書いてあるのだろうか?

     -i      This option will read an unencrypted private (or public) key file

             in the format specified by the -m option and print an OpenSSH

             compatible private (or public) key to stdout.  This option allows

             importing keys from other software, including several commercial

             SSH implementations.  The default import format is “RFC4716”.

このオプションは、-mオプションで明記されたフォーマットの暗号化されていない秘密(または公開)鍵ファイルを読み込み、OpenSSHと互換性のある秘密(または公開)鍵として標準出力に書き出す。このオプションは、いくつかの商用SSHを含む他のソフトウェアから鍵をインポートすることを許可している。デフォルトのインポートフォーマットは"RFC4716"である。

と書いてあるので、超訳すると「商用SSHからOpenSSHに変換するよ!-mオプションつけないならRFC4716フォーマットとして読み込むよ」ということだな。

-m オプションはなんて書いてあるのだろうか?

     -m key_format

             Specify a key format for the -i (import) or -e (export) conver‐

             sion options.  The supported key formats are: “RFC4716” (RFC

             4716/SSH2 public or private key), “PKCS8” (PEM PKCS8 public key)

             or “PEM” (PEM public key).  The default conversion format is

             “RFC4716”.

-i または -e の変換オプションのために鍵のフォーマットを明示する。サポートしているフォーマットは、RFC4716(RFC4716/SSH2 公開または秘密鍵),PKCS8(PEM PKCS8 公開鍵),PEM(PEM公開鍵)。デフォルトの変換フォーマットはRFC4716。

つまり、おいらのメモ書きでは、-m オプションを指定してないってことは、puttykeygenが生成する鍵のフォーマットは、RFC4716ということなのだろうか?

http://www.ietf.org/rfc/rfc4716.txt

うん、どうやらそうらしい。むしろ、「読み込めない!」と思っていた

---- BEGIN SSH2 PUBLIC KEY ----

---- END SSH PUBLIC KEY ----

という書式の方が、準拠なようだ。

 

-f オプションは、キーになるファイルを指定するだけ、らしい。

     -f filename

             Specifies the filename of the key file.

鍵ファイルのファイル名を明記する。

 

ちゃんと調べてみたら、意外と面白かったね。

むしろ鬼子なのは?

Windowsは鬼子、という表現をしてしまったけど、ごめんよ!puttykeygen。

むしろ、puttykeygenで出力された形式の方がRFCに準拠してる形式なんだな。

正直にいうと、「またWindows界隈だけ独自の実装しやがって」とか誤解していました。でも、違うんだね、ちゃんとしてた。

 

こういう、ことがちゃんとわかるから、ちゃんと文書を読んでみる、ということは大切なんだな、ということで。

これからも、適当な思い込みはしないで、ちゃんと文書を読んでみることにする。

 

めちゃくちゃUNIXした 〜これから〜

年末年始の過ごし方

年末年始休暇が終わってしまった。

もっとも、明日がんばれば3連休が控えているから…ちょろいぜ!

この年末年始、日頃やりたくてやれなかったことを、思いっきり消化できたので、とても有意義だったと思う。

 

やれたこと

  • OpenBSDを5.4から6.2にアップデート
  • Scientefic Linuxを6.7から7.3にアップデート
  • 放置プレイだったRaspberryPi(初代)を完動させる
  • オレオレリポジトリの更新
  • 各端末の諸設定の更新
  • 小型液晶ディスプレイの試作

やれなかったこと

 

それでもやれたことは多かった。

とても充実してたな。

忘れていたUNIXをかなり思い出した!

明日から、また、頑張るぞ、と。

自分に都合の良い謎理論は構築して言い訳にしない 〜鍵束を書き換える〜

ログインできないし…

おうちサーバー群へのsshログインを「鍵認証」に切り替えている。

  • クライアント側でssh-keygen
  • 公開鍵(id_rsa.pub)をサーバーの.sshにコピる
  • サーバーの鍵束に登録する(cat id_rsa.pub >> authorized_keys)
  • /etc/ssh/sshd_configでパラメーターを設定

こんな簡単に鍵認証にするのも、メインマシンがOS Xだからなわけで。

シームレスにUNIXと接続できるクライアントPCとしてのMacは高く評価してるよ!

Windowsの頃は、cygwinを入れt(長くなるので割愛

 

なんだがね、やっぱり、Windowsは鬼子だなと思うんだよなぁ。

Windowsにはsshコマンドが標準搭載されていないので

(注)最近は純正sshとかLinuxアプリの整備とか進んでるようです。

(注)それはまた、別の機会に。

どうしても、sshクライアントからのログインになってしまう。

鍵もsshクライアントで使わないとだから、ssh-keydenコマンドを気軽に打てない。

というわけで、長いことPuTTYを愛用してるのだ。

PuTTYにはPuttygenという認証鍵ツールが付いているので、それで鍵を作って、公開鍵をサーバーにアップするのだが…同じ鍵を使ってるのに、サーバーA(ScientificLinux)にはログインできる、サーバーB(OpenBSD)にはログインできないという事例が発生する。

なんでだろ?

科学とは「自分に都合の良い謎理論を立てないこと!」

OpenBSDはセキュリティが強固だっていうからなぁ、Windowsのクライアントで作った鍵の場合は、何か制限があるのかなぁ」とか、謎の理論を構築すること30秒。

いかんいかん!それは、仕事のできない人の発想だ!

自分に都合のより謎理論 = 他人のせい

にしては物事は解決しない。

ということで、ちゃんとした理屈を構築してみることにした。

正常にログインできているサーバーA(ScientificLinux)で、

cat .ssh/authorized_keys してみる。

 

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAq/gO3BA78bK2cce1BlSO4znXyT1a5+ZmguKfxVJSuoywQQXBjw5BZc1tM2uGqYzJ9ZKbgguOsisSLeHKFJZMxkbKsIR5kY/kyj/8KgoI/3N0b8BYkrkWTK2MRZYPd7FOOa6oYfvRlhbiEr1zTOf8cdsOgEKMQZOL/vwjZMqKk7s=

---- BEGIN SSH2 PUBLIC KEY ----

Comment: "rsa-key-20140124"

AAAAB3NzaC1yc2EAAAABJQAAAIEAq/gO3BA78bK2cce1BlSO4znXyT1a5+ZmguKf

xVJSuoywQQXBjw5BZc1tM2uGqYzJ9ZKbgguOsisSLeHKFJZMxkbKsIR5kY/kyj/8

KgoI/3N0b8BYkrkWTK2MRZYPd7FOOa6oYfvRlhbiEr1zTOf8cdsOgEKMQZOL/vwj

ZMqKk7s=

---- END SSH2 PUBLIC KEY ----

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArrePGSahAsMw4NICX48anLCCTHXILqHF2J+ydXe7Bu79aVUcJN6VkfzG6zpyiC0X7Lmapijcz/YhFuT35tfnio8Pvnwrie9gQmJPYRdQDaQ5a/CMCXWgQMy/9VhFd5lobCoBQvjQMIvdCR28Ej+Xqq1sWq0bBlb0I0tXLCCuMNnOSHDxizWIfChix2dM5TN0yX4ROs0LWcyDMRrzy4i32gbplgKnQqM9u2sNNTwIh0HSKE761DR+LBYnzcXyBGBDgJfpHxYjVPfdWfLwtJaSdheJEO2HeB0vfBizhISbUhUqgcfQLJIlvt815MTNDujPdTC62Xa68+eS0Eu8VuUVMQ== hoge@hogehoge.jp

 

上記はその抜粋。

3つの公開鍵が登録されてる。

上から、

1番目はどこの鍵だろう?ま、いっか。

2番目、BEGIN SSH2 PUBLIC KEY はこれは、Windowsで作ったやつだな。

3番目は、OS X で作ったやつ。

2番目と3番目であきらかにフォーマットが違うがこれが原因?

OSは違えどSSHプロトコルは同じなんだから、フォーマットの違いが影響するとも思えない。なぜだろう。

じっと見つめること、30分。気が付いた。

あれ?よくみると、1番目と2番目って、1行にまとまってるだけで書いてあること同じじゃね?ってことは、もしかして、以前、同じことで悩んだりしてる?

ということで、そこを直してみた。1番目と2番目が同じなんだから、2番目を綺麗に削除してみよう。

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAq/gO3BA78bK2cce1BlSO4znXyT1a5+ZmguKfxVJSuoywQQXBjw5BZc1tM2uGqYzJ9ZKbgguOsisSLeHKFJZMxkbKsIR5kY/kyj/8KgoI/3N0b8BYkrkWTK2MRZYPd7FOOa6oYfvRlhbiEr1zTOf8cdsOgEKMQZOL/vwjZMqKk7s=

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArrePGSahAsMw4NICX48anLCCTHXILqHF2J+ydXe7Bu79aVUcJN6VkfzG6zpyiC0X7Lmapijcz/YhFuT35tfnio8Pvnwrie9gQmJPYRdQDaQ5a/CMCXWgQMy/9VhFd5lobCoBQvjQMIvdCR28Ej+Xqq1sWq0bBlb0I0tXLCCuMNnOSHDxizWIfChix2dM5TN0yX4ROs0LWcyDMRrzy4i32gbplgKnQqM9u2sNNTwIh0HSKE761DR+LBYnzcXyBGBDgJfpHxYjVPfdWfLwtJaSdheJEO2HeB0vfBizhISbUhUqgcfQLJIlvt815MTNDujPdTC62Xa68+eS0Eu8VuUVMQ== hoge@hogehoge.jp

で、SSHしてみると…できた!

無事ログインできました。

ってことは、サーバーB(OpenBSD)も同じようなフォーマットにしてやれば…できた!

正しい解

OpenBSDはセキュリティが強固だからWindowsで作った鍵じゃ認証できない」という都合のより謎理論は、やはり成立しなかった。

「公開鍵のフォーマット間違えて登録してました。テヘペロ。」というなんとも恥ずかしいオチでしたとさ。

公開鍵のフォーマットには

OpenSSH形式とSECSH形式があるらしい。

元祖SSHはSECSH形式で、SSHを元に開発されたOpenSSHはOpenSSH形式らしい。

Windowsだからの形式ではなく、きっと、当時、SECSH形式で自分で作ったんだろうなと推測してる。

元祖SSHは触ったことがないから知らなかったよ(恥

言い訳しないで前に進もう

もしも、だ。

OpenBSDはセキュリティが強固だからWindowsで作った鍵じゃ認証できないですね…別にUNIXマシーンで作成した鍵を取ってきて使いましょうよ!」

なんて、言ってしまったら、最悪だ。

なぜかって?

自分が知らないことで、できないことを、さもそれっぽく、誤魔化しているからだ。

知らない人が相手なら騙せるだろう。しかし、知ってる人に言ってしまったらどうなる?あ、こいつ、ダメだな、言い訳してる、とあっさり切られてしまう。

こういう設定ひとつでも、そういうところって出てくるので、怖いと思ったのでした。

ちゃんちゃん。