Nikon D850入手

この前の土曜、散歩から帰ったらD850が届いていた。M店に予約したのは10月末で、中々届かないので忘れていた。その晩は弄るのを我慢し、お急ぎ便でアイカップと液晶保護ガラスを注文。翌朝、届いたそれらを装着していつもの森へ出発。

Nikon D850 (写真のレンズはAF-S NIKKOR 50mm F1.8G)
Made in Thailand シリアルナンバーは20120xx
QXDカードは高価なので当面は手持ちのSDを使おう。

どのレンズを装着するか悩んだ末、AF-S NIKKOR 24-70mm F2.8G EDにする。24-70は現在、VR付きでEタイプの新型が発売されているが、それは持っていない。

共通データ：Nikon D850, AF-S Zoom-Nikkor 24-70mm f/2.8G ED

35.0mm F8.0 ISO=100

Picture Control:Standard

Active D-Lighting:Off

White Balance:5000K
Capture NX-D 1.4.6 W　RAW記録モード：ロスレス圧縮RAW(14bit)

D850は見た感じはこれまで使ってきたD800Eとほとんど同じだが、手に取るとグリップが非常に深くなっていて、すごく持ちやすい。前モデルのD810はスキップしているため、個人的にはこの間の改良点がいっぺんにやってきた感じだ。ファインダーは鮮明で倍率も0.75倍にアップしている。この倍率はフィルム時代のMF機、F3HPと同じだ。有機EL表示も美しくて素敵だ。シャッターを押すと、シャッター音のキレの良さとショックの小ささに驚く。こりゃあいい。今回のD850ではシャッターカウンターバランサーなる新機構が搭載されているという。あれ？ミラーバランサーは？という疑問が残るが、たぶんこれはあれの上位互換なんだろう。ともあれシャッターフィーリングは素晴らしい。
さて画質だが、とりわけ気になるのは細部の鮮鋭度だ。RAWで撮ったものを家に帰ってCapture NX-Dで現像する。予想通り、ピクチャーコントロールのデフォルトでは等倍画像がちょっとボケている。だが、以前のニコンに比べるとだいぶ上品になっている。余計な輪郭強調は無く、ローパスレス機らしい素直な等倍画像だ。

ピクチャーコントロール[SD]のデフォルトパラメータで現像

元サイズ画像(8256x5504=45.44MP)ダウンロード

デフォルトパラメータではつぶれてしまっている細部の情報を引き出すために、Capture NX-Dでピクチャーコントロールの輪郭強調を0にした上で、アンシャープマスクをかける。D850の場合、半径=２・適用量=100が適当に思える。良く解像した等倍画像になり、細部の質感が見えてくる。ただし、等倍鑑賞が目的でなくリサイズやプリントする場合にはデフォルトパラメータからの方が良い解像感が得られる場合があるので、出力サイズと元画像にかけるアンシャープマスクの半径との関係については研究が必要である。

ピクチャーコントロールの輪郭強調=0

アンシャープマスク　適用量=100　半径=2

元サイズ画像(8256x5504=45.44MP)ダウンロード

ピクチャーコントロールに明瞭度のパラメータがある。これをちょっと増やしてやると中判ぽい雰囲気になる。画面サイズの差は光学的に決して超えられない壁であることは確かで、中判カメラのくっきり感が「明瞭度」なる画像処理で高度に模倣できるものだとは思わないが、本物ではないにせよある意味・ある程度、それっぽい雰囲気になる。

明瞭度=3.5

元サイズ画像(8256x5504=45.44MP)ダウンロード

AF-S NIKKOR 24-70mm F2.8G EDは、1200万画素のFX初号機であるD3と同じ2007年に発売されたレンズだ。中央部分は非常によく解像するものの、ワイド側の像面湾曲が顕著で周辺部がかなり前ピンになるという独特な性質を持っている。被写界深度でどうにかなる程度ではなく、遠景やこのような平面が相手だとF8~F11まで絞っても周辺像が甘くなる。念のために言っておかなければならないが、決して悪いレンズではなく、絞り解放時や逆光でもコントラストが高く非常に美しい描写をするし、ピントが合っている限りにおいては画面周辺部でも素晴らしい解像力で、ポートレートにも適している。ただ、構図を選ぶレンズなので風景では扱い辛い場面が多く、標準域をカバーする万能高級ズームという位置付けながら、実のところかなりの癖玉といえる。24-70は先ごろVR付きの新型、AF-S NIKKOR 24-70mm f/2.8E ED VRにモデルチェンジしているので、そこらへんがどうなっているか興味はあるが、いかんせん高価なためD850用に新たに購入する予定は無い。

ゴムボールが何個あるか数えてみよう。
Nikon D850, AF-S Zoom-Nikkor 24-70mm f/2.8G ED

28.0mm F8.0 ISO=400
ピクチャーコントロールの輪郭強調=0
アンシャープマスク　適用量=100　半径=2
元サイズ画像(8256x5504=45.44MP)ダウンロード

上と同じAF-S NIKKOR 24-70mm F2.8G EDにて。信号塔の手前の策が奥の方へ円弧状に広がっており、このレンズには不得意な構図といえる。

Nikon D850, AF-S Zoom-Nikkor 24-70mm f/2.8G ED

24.0mm F8.0 ISO=100

ピクチャーコントロールの輪郭強調=0

アンシャープマスク　適用量=100　半径=2

元サイズ画像(8256x5504=45.44MP)ダウンロード

今回はこれまで。次回からは4500万画素の実力を最大限に引き出すべく、手持ちのレンズや現像時のパラメータを色々試していく予定である。

どどっと400(1995)

中野Ｆ店Ｊ館にて「どどっと400」を発見。1995年に３本セットで発売された「ニコンおもしろレンズ工房」うちの一本だ。詳しくはニッコール千夜一夜の記事を参照されたし。現代のトイレンズはわざとポンコツな描写を狙ったものが主だが、当時のコレは簡素な構造ながら良く写ることを狙ったものであり、そういう意味では今のトイレンズとは訴求方向が異なっている。

ニコンおもしろレンズ工房 どどっと400 (1995)

400mm F8.0

1983年頃、これに似た構造ものでケンコーの「クローズアップ鏡胴セット」というものを持っていた。当時のクローズアップレンズは現在でもまだ持っているが、肝心の鏡胴の方を紛失してしまい、今となってもうは遊ぶことができない。クローズアップ鏡胴セットは52mm径のクローズアップレンズ（AC No.3・AC No.5・No.2）を使い、330mm F6.3と200mm F4、125mmのソフトフォーカスレンズを作ることができた。簡素なレンズとカメラマウントが取り付けられた金属製の筒と、ヘリコイドの代わりに斜めに溝があけられた内部のチューブでフォーカシングするというどどっと400の機構は、クローズアップ鏡胴セットにそっくりだが、どどっと400はクローズアップレンズを流用するのではなく、専用の2群4枚のテレフォトタイプの光学系が最初から組み込まれている。テレフォトタイプなので焦点距離の割に全長が短く、鏡胴を前後に分割してコンパクトに収納することができる構造になっているが、光学系が組み込まれた前部鏡胴は分解することはできない。前玉のフィルター径は52mm・F値はF8.0で、ケンコーのように自作絞りを入れる構造は無い。マウント部分はプラスチックである。

発売時は他の二本のレンズ（ぎょぎょっと、ぐぐっと/ふわっと）とともに、Nikonロゴやエンブレム風のステッカーが同梱されていたらしいが、現在は1000円の値札が奢られており無常観を盛り上げている。

カメラボディにに装着した状態。
週末は丁度良い天気だったのでこのレンズを持って出かけてみる。ファインダーは暗く、ミラー切れで視野枠上方にはカゲリが出る。フォーカスエイドは使えないものの、マット面でフォーカシングをすることができる。フォーカシングチューブの操作は滑らかではないが、クローズアップ鏡胴セットよりはガタも少なく操作がしやすいように思える。
望遠レンズの拡大威力と言っていいのだろうか、そういうものを感じる目的で、50mmで撮影したものとどどっと400の画像を比べてみよう。

f=50mm F8.0

Nikon D800E, AF-S NIKKOR 24-70mm F2.8G ED

元サイズ画像(7360x4912 pix)

f=400mm F8.0相当

Nikon D800E, おもしろレンズ工房 どどっと400

元サイズ画像(7360x4912 pix)

シャープ補正＋軸上色収差補正＋コントラスト補正

元サイズ画像(7360x4912)

当たり前だが、400mmなので50mmに比べ8倍の倍率で遠方が拡大されて写る。と同時に、ナノクリズームの圧倒的なコントラストにも関心する。どどっと400はレンズ内面が曇っており、ハレ切りはしているものの猛烈にコントラストが低い。解像力は素晴らしいわけではないが、周辺光量不足もなく周辺まで画質が均一で、その点では良く写っている。下の画像は、Caputure NX-Dで現像時に軸上色収差とコントラストを補正し、シャープのパラメータを変更したもの。
Amazonにカニ目レンチを注文したので、内面のクモリを清掃してから、後日また撮ってみようと思う。モノコートレンズとはいえ、2群4枚というシンプルな構成で、鏡胴内も通常のレンズと変わらず丁寧に溝が掘られ艶消し塗装が施されている。レンズを拭けばもっと良く写るに違いない。

台風一過

朝起きると空気のよどみが吹き飛ばされ晴れ渡っている。絶好のシーイングを期待して望遠レンズを担いで出かけてみたが、思いのほか暑くなり、午後になるとややガスっぽくなった。

 Nikon D800E, AF-S NIKKOR 200-500mm f/5.6E ED VR

Raspberry Pi Zero Wでワイヤレスシリアルコンソールサーバー

Raspberry Piを使って、4G LTE回線とインターネット経由で、ワイヤレスアクセスできるシリアルコンソールサーバーを作成した。ルーターやサーバーなどのネットワーク機器のシリアルコンソールにリモートアクセスして、いわゆるOOBM（Out-Of-Band-Management）というオペレーション行うための装置だ。こういった用途には、かつてはアナログモデムと電話回線が使われていたが、専用のアナログ電話回線を用意しなければならず、コスト的にも割高なこの方法は現代では敬遠されつつある。ルーターやサーバーなどのネットワーク機器は、通常TelnetやSSH接続を使ってインバンドで管理されるが、回線障害や設定ミスなどによりリモートログインができなくなってしまった場合や、機器の導入時に専任の担当者が遠隔操作で初期設定を行う場合などは、こういったOOBMの手段が有用となる。3G/4G回線を使う「セルラーモデム」という専用のデバイスがあるそうだが、産業用などに使われる高価な代物のようで、一般のオフィスはもちろんデータセンターなどでもあまりお目にかかったことは無い。代替手段としてはリモートデスクトップ経由でのアクセスや、Ethernet経由のコンソールサーバーなどがあるが、セキュリティ上の事情や責任分界点の関係で、リモートサイトでこういった手段が使えない場合もある。今回は、こういった課題を解決することができる手段の一つとして、安価に手に入るRaspberry Piとモバイルルーターを使ったOOBMデバイスを作成したのでご紹介したい。なお、具体的なビルド方法については、公開するための整理ができていないので、恐縮ながら今回は割愛させてもらう。

リモート側デバイス。今回のシステムでは「モバイルコンソール」と呼ぶ。

Raspberry Pi Zero Wを使ったもの（上）

Raspberry Pi 1 Model Bを使ったもの（下）

最近日本でも入手ができるようになりつつある「Raspberry Pi Zero W」。

GPIO端子のひとつにステータス表示用のLEDを接続し、サーバーとのSSHトンネリングが完了したらこれを点灯させる仕組みだ。Raspbianを使う動作環境や動作用のスクリプトはRaspberry Pi各モデルに共通なので、有線LANポートのついたこれまでのRaspberry Piモデルも使用できる。最初のデバイスは、デスクの引き出しで眠っていたRaspberry Pi 1 Model Bを使って作成した。リモート側のデバイスは、Raspberry Pi本体と電源、USBシリアル変換ケーブル、それにモバイルルーターによって構成される。このセットを今回は便宜上「モバイルコンソール」と呼ぶ。（もっと素敵な呼び方があれば変更してもいい）
Raspberry Pi 1 Model Bは無線LANを内蔵していないので、Wi-Fiでインターネットに接続するにはUSBの無線LANアダプタが必要になる。Raspberry Pi Zero Wは無線LANはあるが有線LANポートを持たないので、有線接続をしたい場合にはマイクロUSB-RJ45のLANアダプタが必要になる。現在主流のモデル、Raspberry Pi 3 Model Bは有線LANポートと無線LANアダプタを内蔵しているのでこれが望ましいが、消費電力がやや大きいため別途専用のACアダプターが必要になる。

資料用に作成したスライド。

モバイルコンソールのRaspberry Piは、起動後自動的にインターネット上の中継サーバーにSSHトンネルを張る（掘る？）仕組みになっている。今回のシステムでは接続の中継に使うこのサーバーを「Pi Server」と呼ぶことにした。当初、Pi Serverは先日の企画でも使った趣味用途で個人契約しているVPSを使っていたものの、本来このサーバーではパスワード認証を有効にしたくない。しかし、仕事で使うことを想定すると鍵を使っての認証は手順が煩雑すぎ、利便性を優先するとやはりパスワード認証が好ましい。そこで、当初リモート側デバイスとして使っていたRaspberry Pi 1 Model Bのハードウェアを流用し、独立したこの目的専用のサーバーを用意することにした。中継用のPi ServerはSSHDが動作するLinuxシステムなら何でも良いが、インターネットから接続するためのグローバルIPは必要になる。

図中のIPアドレスは架空。

ユーザーがモバイルコンソールへ接続するには、PuTTYやTeratermなどのSSHクライアントを使ってPi ServerのインターネットアドレスへSSH接続をおこなうだけでいい。接続に必要なパラメータは「Pi ServerのIPアドレス」「ユーザー名」「パスワード」「ポート番号（443固定）」だけだ。

Pi Serverへログインする際のユーザー毎に、ループバック接続をするポート番号を各々割り当て、対応するモバイルコンソールデバイスへ接続させる仕組みになっている。これにより、一台のPi Serverを多数のモバイルコンソールの中継に使うことができる。今のところモバイルコンソールと呼んでいるが、多数のリモートサイトに常設するような使用方法を想定してもいい。その場合、同時に稼働できるモバイルコンソール数の上限は、サーバーがSSHトンネリングのTCPセッションを同時にいくつ維持できるかによるため、実際のところは不明だが、数十か数百あたりではないかと思う。SSHサーバー側は公開鍵認証にも対応させているが、利便性を優先しパスワード認証でのログインを有効にしてある。トンネルを張る際のSSHセッションの非対話ログインにはsshpassというプログラムを使っており、このプログラムはSSHサーバー側がパスワード認証でも公開鍵認証のパスフレーズ付きまたはパスフレーズ無しのいずれの場合でも動作するので、サーバー側の認証方式を変更してもモバイルコンソール側のスクリプトに変更の必要は無い。モバイルコンソール側のターミナルソフトにはLinuxの「cu」を使っている。これの代わりに「jerm」というプログラムを使えばシリアルポートをTCP接続に変換することが容易なのだが、jermはTCP接続経由では「ブレーク信号」を送ることができないことがテスト中に分かったため、採用を断念した。ブレーク信号の送信は、CISCOルーターのブート時にROMMONに入るために必要な操作で、これができることは重要である。

モバイルコンソール側とこれにリモート接続する管理者側では、ファイアーウォールやルーター上にポート開放などの設定を追加する必要は一切無い。インターネット上のPi Server（固定IPまたはDDNS）に対してモバイルコンソール側と管理者側の両側から、TCP 443ポートへのTCPセッションを外向きに開始するだけなので、モバイルルーターやブロードバンドルーターのIPマスカレードNATを超えて、また片方あるいは双方がファイアーウォールの内側にあっても接続が可能である。TCP 443ポートはTCP 80番同様、極めて一般的なポートなので、企業内のファイアーウォールでも外向きの接続がブロックされることはほぼ無い。（FWによってはダメな場合はある）

接続の仕組み。

その他の機能。

モバイル回線やインターネット接続が不安定な場合や、DHCPのリース期限切れなどにより、モバイルコンソールとPi Server間のトンネルセッションがダウンする場合がある。その場合に備え、モバイルコンソール側ではスクリプトを使って自動的にトンネルを復旧させる仕掛けを設けてある。実はここが最も苦労した点で、当初はnmapとpgrepを使ってポートが開いているかどうかと、プロセスが存在するかどうかによってチェックをしていたが、トンネルセッションを起動したSSHプロセスが残っているのに通信できない場合があったり、リモート側の回線が切れているのにサーバー側のTCP接続が残留し続け、回線復旧後に自動再接続をしてもポートのバインドに失敗したりなど、通信できないといっても色々なパターンがあり、トンネルのダウンを客観的に検出するのが結構難しかった。確実に異常を検出するために、最終的に行ったのは「トンネルループバックテスト」と呼んでいる方法だ。これは待機時に張っているトンネルとは別に、一時的にチェック用のトンネルをサーバー向けに作成し、ワンラインでSSHコマンドの後ろに追加したコマンドをサーバー側で実行させ、待機中のトンネルを折り返してリモート側のディレクトリにテンポラリファイルを作成させる方法である。コマンド実行後にテンポラリファイルが存在しなければトンネルが機能していない、というわけだ。これにより、トンネルが正常に機能しているかどうかを割と確実に検出することに成功した。

その他の機能としては、モバイルコンソールになるRaspberry Piが有線LANポートを持っている場合は、無線LANでのインターネットアクセスと合わせ、ルーターとして機能させることができる。モバイルコンソールデバイスをサイトに常設することで、メインの通信回線がダウンした場合のバックアップ回線に4G LTEインターネット回線を割り当てる「セルラーフェイルオーバー」用のデバイスとしても同時に使用することができる。Raspberry Piをルーターとして動作させた場合、回線側が高速でも実行スループットは4.5Mbps程度のようなのであまり高速とは言えないが、バックアップ用途であればこれで十分な場合もあるだろう。なお、有線LANポートはトンネルを張るためのインターネット接続にも使用できる。ブロードバンドルーターのLANポートや企業内の既存のイントラネットなどに有線接続し、NATやファイアーウォールを通ってインターネットへ抜けることが出来さえすればトンネルを張ることができる。有線LANポートのIPアドレスは、Raspberry Piの起動時にDHCPでの取得が試行され、DHCPサーバーからの応答がなければあらかじめ設定済みの固定IPアドレスになるようにしてある。モバイルコンソールはFTPサーバーも有効にしてあり、有線LANポートからFTPサーバーへアクセスする際はこの固定IPを使えばいい。

今回、SSHDが作動する中継サーバー「Pi Server」はADSLのインターネット回線に接続した。この回線は、ISPの固定IPアドレスオプションを契約しているが、DDNSを使う方法でも構わない。回線事業者が提供するモデムルーターに設定を追加し、インターネットからTCP 443宛の接続をLAN内のPi Serverに転送するわけだが、今回使ったこのNTTフレッツADSL用のモデムルーター（NVIII）は、ポート番号を指定してLAN内の任意ホストへ転送する機能が無いらしい。プロトコルに関わらずDMZとしたLAN内の任意のホストへ転送することはできるようなので今回はその機能を使うことにした。Pi ServerはSSHD以外のポートは開いていないが、念のためiptablesの設定でTCP 443宛の接続以外はDROPするようにしている。

モバイルコンソールを使用するためにPi Serverに接続したユーザーは、.bash_profileの記述によってログイン後すぐにSSHコマンドが起動されてモバイルコンソールへ転送され、ログイン後にまたすぐに.bash_profileで自動的にcuプログラムが起動される仕組みになっている。仕組み上、Pi Serverからモバイルコンソールへの転送中に^Cを連打すればPi Serverかモバイルコンソール上のコマンドプロンプトに抜け落ちてしまうことは可能で、また、cuプログラムにはシェル経由でコマンドを実行することができてしまう$!エスケープシーケンスがあるため、想定しないシェルコマンドがユーザーによって実行されるのを防止するために、Pi Server側とリモートコンソール側で使用されるユーザーは、rbashによるコマンド制限を行っている。Pi Serverには通常のシェルコマンドを実行することができる管理用のユーザーも用意してあり、トンネルを通ってリモート側のRaspberry Piにログインすることができる。これを使って、新しい無線LANアクセスポイントを使う場合のパラメータ設定や、cuコマンド起動時のシリアルポートのスピード変更などを行う。

バージョンアップ履歴。

SSHトンネリングを使ってNAT/FW超えする機能は当初からあったが、初期バージョンは一台のモバイルコンソールにしか対応していなかった。その後のバージョンアップで、複数デバイスへの対応やトンネル切断時の再接続方法の見直し、GPIOを使ったステータスLEDの実装、パスワードファイルの暗号化や公開鍵認証への対応などを行い、最終的には中継サーバーもRaspberry Piを使う現在の方式にした。

途中のマイナーバージョンアップでは、TTSエンジンとWaveファイルによる音声ステータスの機能をひそかに実装した。これはアナログオーディオジャックのあるRaspberry Piモデルで有効で、起動時にDHCPで取得したインターフェースのIPアドレスやESSID名、トンネルの接続状況や再接続中のステータスなどをイヤホンや小型スピーカーから音声出力させるものである。日本語にはTTSエンジンOpen JtalkとMMD Agentの音響モデル「メイ」、英語にはESPEAK TTSを使っている。なお、Raspberry Pi Zero Wについては、せっかく付いているBluetooth経由での音声出力も実験してみたが、接続が不安定でペアリングの操作もたびたび必要なことから実用的ではなく、実際のところGPIOに接続した一灯のLEDでも十分に用を足すので、Raspberry Pi Zero Wではしゃべる機能は使っていない。

また、最新のバージョンでは、シリアルコンソールを使用中のユーザーが一文字づつタイピングしている様子を、別のセッションからリモートデスクトップの画面共有のようにリアルタイムに表示することができる機能を装備した。ちょっと不思議な機能だが、方法は意外と簡単で、cuコマンドにはログを出力する機能が無いが、scriptコマンドを使えばログの記録が簡単にでき、-f オプションを付けることでファイルがリアルタイムに保存されるので、別のセッションでPi Serverの管理用ユーザーにログインし、記録中のログファイルをtailfコマンドで表示させるだけである。

D850正式発表

ニコンの新型ボディD850が発表になった。D810は購入を見送ったので今回は買う。入手出来次第お知らせする。

週末に「ファンミーティング」なるイベントがあり、物見遊山で行ってはみたものの人がいっぱいでD850には触ることができなかった。

パスワード管理ソフトKeePassのデータベースを自前サーバーに置いてSFTPで同期する

KeePassでパスワード管理する前に、まずはブラウザが保存しているパスワードがないか確認して、あればすべて削除する。

ブラウザが保存しているパスワードを確認するにはこれを使う。

WebBrowserPassView v1.86 

http://www.nirsoft.net/utils/web_browser_password.html

TeamViewerが乗っ取られた際に、このWebBrowserPassViewをインストールされる例もあるらしいので、ブラウザでパスワードを保存していると大変なことになる。

ブラウザが保存しているパスワードがあればこのウィンドウに表示される。

ブラウザが保存しているパスワードを削除する

Chromeの場合

設定→ユーザー・同期→同期の詳細設定で、パスワードの同期をオフにする。

設定→一番下の詳細設定→パスワードとフォーム・パスワードを管理で保存されているパスワードをすべて削除し、パスワードの管理をオフにする。

「Chromeにログインし、パスワードを同期させている場合」は、自分が使っている他のPCのChromeにもパスワードが同期されてしまい各PC内に保存されているので、

同期させているPCのChromeでも保存されているパスワードがあれば全て削除する。

ブラウザが保存しているパスワードを全部削除したら、WebBrowserPassViewでふたたび確認して空っぽならOK。


Keepassのデータベースを自前サーバーに置いてSFTPで同期する
Keepassの使い方やDropBoxにデータベースを置く方法については他にも説明をされている方がたくさんいるので割愛させていただきたい。今回は、SSHサーバーとSFTPが使える状態の自前サーバー（VPS)にデータベースを置いてKeepassから参照する方法をやってみる。

KeePass
ダウンロード
http://keepass.info/

SFTPを使うにはKeepassにこのプラグインが必要になる。
IOProtocolExt
ダウンロード

http://keepass.info/plugins.html#ioprotocolext

 ダウンロードしたファイルを展開し、１個のディレクトリと2個のファイルをKeepassのあるフォルダーにコピーする。

Keepassを起動し、「ツール」メニューの「プラグイン」を開いて確認する。

IOProtocolExtが読み込まれていればOK。

次に、ローカルドライブに作成したKeepassdデータベースファイル（.kdbx)をWinSCPプログラムやRLoginプログラムなどを使ってサーバーにあらかじめ転送しておき、Keepass起動時にこれをSFTPで読み込むように指定する。

WinSCPで使うPuTTY形式の秘密鍵(.ppk)を作成する

サーバー側のSSHDがパスワード認証の場合はこの手順はスキップしていただきたい。サーバー側が公開鍵認証の場合、WinSCPが読み込むことができるPuTTY形式の秘密鍵(.ppk)を作成する必要がある。PuTTYのインストールフォルダにあるPUTTYGEN.EXEを使って作成するが、今回は既にOpenSSHで作成した秘密鍵があるので、PUTTYGEN.EXEを使ってPuTTY形式(.ppk)に変換したものを使う。公開鍵(.pub)はサーバー側のユーザーディレクトリ内　~/.ssh/authrizedkeyファイルに既に登録されているものとする。

PUTTYGEN.EXEをダブルクリックで起動。

 「Load」でOpenSSHで作成した秘密鍵ファイルを読み込む。

OpenSSHを使っている場合、デフォルトではユーザーディレクトリの.sshフォルダ（隠しフォルダ）内に秘密鍵・公開鍵・knownhostsのファイルがある。

 All Filesを選択し、OpenSSHで作成した秘密鍵「id_rsa」を読み込む。

 秘密鍵にパスフレーズが設定されている場合はここで入力する。

 パスフレーズが正しい場合は読み込みが成功する。

 読み込んだ状態で、「Save private key」ボタンを押せばPuTTY形式(.ppk)で保存することができる。

 ここでは、元のファイル名「id_rsa」に.ppkをつけた「id_rsa.ppk」とう名前で保存。

KeepassでSFTPからデータベースファイルを読み込む
「ファイル」メニューの「開く」「URLから開く」を選択。

URL:データベースファイル名をフルパスで入力する。
例）sftp://xxx.xxx.xxx.xxx:22//home/user1/ftp/keepass/MYKEEPASSDB.kdbx
ユーザ名：ユーザー名
パスワード：パスワード認証の場合はここに入力。公開鍵認証の場合は空欄のままにする。（パスフレーズをここに入力すると失敗する）
記憶する：ここは任意に選択。公開鍵認証の場合、ここではパスフレーズは保存できないので「ユーザー名のみ覚える」が選択可能。

公開鍵認証の場合「拡張」タブの中で、秘密鍵のファイル名を指定する。

SSH private key pathのところに秘密鍵のファイル名を指定する。

パスフレーズの入力

FTPS/SCP/SFTPのPassphraseのところ入力する。（ただし、入力すると平文で表示されるので注意）

「OK」ボタンを押し、SFTPでのログインが成功するとKeepassのマスターキーを入力または選択するダイヤログボックスが開く。

マスターキーを入力・選択後「OK」ボタンを押すとKeepassデータベースが読み込まれる。

Keepassウィンドウが表示されれば完了。

エントリーを変更した場合にデータベースを自動的に保存するように設定するように「ツール」「オプション」メニューで設定をおこなう。

「データベースをロックまたは閉じるときに自動的に保存」にチェック。

以上。