気の向くままに辿るIT/ICT/IoT
システム開発

NetBSDでSSH

ホーム前へ次へ
NetBSDのインストールと運用/NetBSD/i386 6.1.x編

NetBSDでSSH

NetBSDでSSH

 暗号化と認証技術を併用し、安全な通信路を確保するSSH/Secure SHellには、各種実装がありますが、最も広く知られているものにOpenSSHがあります。

 SSHは、サーバを起動するだけで他マシンのリモート操作を行なうSSHに加え、安全な通信路を使ってコピーを行なうSCP/Secure CoPy、同じくファイル転送を行なうSFTP/Secure FTPを標準で利用でき、さらにポートフォワーディング技術との併用により、いわゆるSSHトンネルを通してメールやVNCなど各種サービスプログラムを実行でき、その場合、SSHポートを使うため、これを通すプログラム用のポートを開放する必要がないという副産物もあります。

 sshとscpは、r系コマンド(rlogin/rsh/rcp)のセキュリティ強化版ともいえ、これらの置き換えを意図しています。

 尚、SSHは、SSLとは別の技術です。

 もちろん、NetBSDでもSSHを利用することができます。

NetBSDでSSHサーバを構築

$ sudo /etc/rc.d/sshd onestart
      or
$ sudo vi /etc/rc.conf
...
sshd=yes
...
$ sudo /etc/rc.d/sshd start
$

 NetBSDで、SSHサーバを構築するというと大げさですが、SSHデーモンを起動するには、一時的なら/etc/rc.d/sshd onestart、常時なら/etc/rc.confにsshd=yesと追記後、マシンを(再)起動するだけです。

 構成ファイルは、SSHサーバ用の/etc/ssh/sshd_configとSSHクライアント用の/etc/ssh/ssh_configがあり、少なくとも検証時点においてはデフォルトでscp、sftpは有効となっています。

 SSHクライアント用構成ファイルについては、ユーザーごとの設定は、~/.ssh/configで(なければ新規作成するなり、/etc/ssh/ssh_configをコピーするなりして)行ないます。

パスワード認証(既定)

$ ssh username@hostname
Password:
...
$
      or
$ ssh hostname
Password:
...
$ scp file_name username@hostname:~/
Password:
$
      or
$ scp hostname:~/abc.txt .
Password:
$
...etc.

 sshd起動後は、sshでデフォルトのパスワード認証でリモートホストにログイン、この時点で後述するGUI機能は別として、自ホストにログインしたのと同じ状態で操作可能となりますし、scpでリモートホストからローカル、ローカルからリモートホスト相互にコピーすることができ、ユーザー名が同名なら、[username@]は省略可能です。

 尚、hostnameとディレクトリ(ファイル)の間にはコロンが1つ必要となります。

 ちなみにhostnameの利用にあたっては、/etc/hostsなどで名前解決ができていて/etc/hosts.allowや/etc/hosts.denyがないか適切に設定されていることが前提です。

 もちろん、hostnameの代わりにIPアドレスを使うこともできます。

鍵認証

 ただ、パスワード認証は、近年のPCの高性能化などに伴って解読も高速化、総当たりでもそれほど時間がかからなくなってきており、安全性が高いとは言い難いので鍵認証の利用が推奨されます。

$ cd ~/.ssh
$ ssh-keygen
...
$ scp id_rsa.pub hostname:~/.ssh/
$ ssh hostname
Password:
...
remote_host$ cd ~/.ssh
remote_host$ id_rsa.pub >> authorized_keys
remote_host$ rm id_rsa.pub
remote_host$ chmod 700 ~/.ssh
remote_host$ chmod 600 ~/.ssh/authorized_keys
remote_host$ exit
$

 秘密鍵を利用する場合、まず、クライアント側でssh-keygenコマンドなどを使って秘密鍵と公開鍵を作り、scpで公開鍵(*.pub)をリモートホスト(SSHサーバ)の~/.sshディレクトリにコピーするなりして同じく~/.sshで(リダイレクトにしても予め用意するにしてもなければ作成した)authorized_keysファイルに追記(つまり、マシンが複数ある場合でも対応可能)、リモートホスト上の/etc/ssh/sshd_configファイルを適宜設定します。

 この時、リモートホスト側に~/.sshディレクトリがなければ、ssh経由でもよいので作成、rootではなく、ユーザー権限でパーミッションを700とし、authorized_keysはこれを600としておきます。

$ ssh-copy-id -i id_rsa.pub hostname
$

 ちなみに、公開鍵をサーバにコピーする際、scpではなく、ssh-copy-idコマンドを使うと仮に指定した公開鍵ファイルの.pubを忘れた場合でも拡張子が自動で追加されたり、hostnameの指定だけでhostname(ユーザー名が異なる場合には、username@hostname)の~/.ssh/authorized_keysとしてコピーされるようなので、より簡単かもしれません。

 尚、構成ファイル上のデフォルトでは、秘密鍵ファイルは、id_*(秘密鍵)とid_*.pub(公開鍵)が作成され、実際には、ssh-keygenコマンドを引数なしで実行し、対話的にデフォルトを選択したid_rsaとid_rsa.pubを利用、これらは、ローカルでも~/.sshに置くので~/.ssh内で実行するのが手間が少なく妥当、また、先のauthorized_keysというファイル名も構成ファイル上のデフォルト値です。

 ただし、RSA1は、SSHプロトコル1で唯一の鍵認証を使ったデジタル署名方式であり、より新しいSSHプロトコル2では、RSA/DSA/ECDSA/ED25519を利用することができ、今となってはRSA1は、認証強度が弱いことからSSH2で利用可能な他の鍵認証方式を使うことが推奨されます。

$ ssh hostname
...
Password:
...
remote_host$ sudo vi /etc/ssh/sshd_config
...
#RSAAuthentication yes
#PubkeyAuthentication yes
(コメント記号#を外す)
...
remote_host$ /etc/rc.d/sshd restart
remote_host$ exit
$

 ここではssh-keygenのデフォルトに合わせて敢えてRSAを使うものとすると/etc/ssh/sshd_configファイルにおいて[RSAAuthentication yes]、[PubkeyAuthentication yes]行がコメントアウトされているので(RSA以外は後者のみ)先頭の#を取ってRSA認証や公開鍵認証を有効にして(構成ファイルを編集した場合には、再読み込みさせるため、必ず)/etc/rc.d/sshd restartします。

 初めてsshやscpを実行するにあたり、ssh-keygenコマンド実行時にパスワードを入力した場合には、パスワード入力を1回、そうでない場合には、即、ログインやコピーが行なわれますが、何らかの事情で鍵認証がうまく機能しなかった場合には、継続するか否かのyes/noを求められることになり、yesを選択するとパスワード認証用のログインパスワードを求められることになります。

 鍵認証に失敗した場合には、原因を探し、修正しておきます。

 たいていの原因は、デフォルト含め、RSA認証を使った場合、特に[RSAAuthentication yes]、[PubkeyAuthentication yes]行が、他の鍵認証を使う場合も後者が、無効になっていることやホストとIPアドレスのマッピング(名前解決)がうまくいっていないことでしょう。(後者については、リモートホスト側のマシンがマルチブート構成で何らかの事情で各OSごとに同一IPに対してホスト名を変えており、それぞれをサーバとして検証した場合なども該当する可能性あり。)

$ ssh hostname
Password:
remote_host$ sudo vi /etc/ssh/sshd_config
...
#PasswordAuthentication yes
      or
PasswordAuthentication no
(コメント記号#を付けるか設定値をnoとする)
...
PermitEmptyPasswords no
...
remote_host$ /etc/rc.d/sshd restart
remote_host$ exit
$

 うまく鍵認証が機能し、パスワード認証を無効にしておきたい場合には、[PasswordAuthentication yes]行をコメントアウトするか、設定値を[no]として/etc/rc.d/sshd restartしておきます。

 その後もパスワード認証とは別にsshやscpの実行ごとに鍵認証(暗号化解除)用のパスワードを求められることになりますが、対話式の場合には、鍵認証した上で鍵認証用のパスワードを設定しておくことは、暗号化されないとはいえ、より安全性が高まるものであり、パスワードを設定した場合には、パスワードなしでアクセスすることはないはずなので/etc/ssh/sshd_configファイルにおいて[PermitEmptyPasswords]の設定値は[no]としておくとよいでしょう。

 ちなみにマシンの電源を頻繁に落とすことがないような環境においてcron起動を含むスクリプトなど非対話式での実行に実用的に、かつ、より安全に使えるよう鍵認証用のパスワードを都度入力しなくても済むようにしたい場合には、sshではなく、デーモンであるssh_agentとkeychainを利用するとよいでしょう。

 尚、SSHで設定できる項目はこれに留まらず、相当数が多く、リモートホスト側は/etc/ssh/sshd_config、クライアント側は/etc/ssh/ssh_configで多彩な設定ができるので、これら以外の設定については、必要に応じて調べてみるとよいでしょう。

 例えば、sshは、r系コマンドの置き換えを想定していることもあり、弱い認証方法といえども認証を重ねることで多少なりとも強度が上がるという意味もあるのでしょう、各種認証に併せて.rhostsファイルのチェックも行なうか否かの設定値もあったりします。

SSHでリモートホストのGUI機能を使う

$ ssh hostname
Password:
remote_host$ sudo vi /etc/ssh/sshd_config
...
#X11Forwarding yes
...
remote_host$
remote_host$ /etc/rc.d/sshd restart
remote_host$ exit
$ ssh -X hostname
remote_host$ firefox &

 このままだとリモートホスト上では、CUIベースになりますが、リモートホスト上の/etc/ssh/sshd_configで[X11Forwarding yes]を有効にし、クライアントでX11 Forwarding機能を利用する旨を通知する[-X]スイッチ、場合によっては当該機能を信頼済みであることを示す[-Y]スイッチを付けてsshアクセスすれば、WindowsやMac OS XなどからLinux/*BSD/PC-UNIX他のX Windowシステムを、またその逆を使うことができるOpenSSHの一機能が用意されています。

 確認時点では、NetBSDの/etc/ssh/sshd_configではデフォルトで[X11Forwarding yes]がコメントアウトされ無効(Fedora/Linuxでは有効)になっており、(Fedora/Linuxと違い、)X11モジュール用と思われるpkgsrcからxorgを使う場合に有効にする必要があると注記されている[#XAuthLocation /usr/pkg/bin/xauth]行もありました。

 SSH接続できることは前提、NetBSDをSSHサーバをとした場合、具体的には、次のようになります。

local_host$ ssh hostname
Password:
remote_host$ sudo vi /etc/ssh/sshd_config
...
X11Forwarding yes
X11DisplayOffset 10
...
remote_host$ /etc/rc.d/sshd restart
remote_host$ vncserver :10
remote_host$ exit
local_host$

 まず、SSHサーバ側の/etc/ssh/sshd_configで[X11Forwarding yes]、[X11DisplayOffset 10]のコメントを外して有効にし、SSHサーバをrestart(/etc/rc.d/sshd restart)、先の[X11DisplayOffset]の設定値をディスプレイ番号としてvncserverを起動しておきます。

remote_host$ exit
local_host$ cp /etc/ssh/ssh_config ~/.ssh/config
local_host$ sudo vi ~/.ssh/config
...
ForwardAgent yes
ForwardX11 yes
...
local_host$ ssh -X hostname
Password:
remote_host$ echo $DISPLAY
localhost:10.0
remote_host$ caja &
remote_host$ pluma &
remote_host$ xterm &

 次にSSHクライアント側の/etc/ssh/ssh_config、もしくは、これをコピーするなりして作成したユーザー個別設定用の~/.ssh/configで[ForwardAgent yes]、[ForwardX11 yes]のコメントを外して有効にし、SSHサーバをrestart(/etc/rc.d/sshd restart)、SSHクライアントから[ssh -X ssh_server](ユーザーが異なる場合には、username@ssh_server)とし、sshログインします。

SSH X11ForwardingによるGUI各種アプリのリモート操作
SSH X11ForwardingによるGUIリモート操作
SSHサーバ:NetBSD/ノートPC
SSHクライアント:LXDE/Fedora/デスクトップPC

 そのまま端末から[caja &]、[pluma &]、[xterm &]などとしてアプリケーションを実行するとSSHクライアントの画面上にSSHサーバ側のGUIアプリケーションが起動します。

 サンプルの画像は、デスクトップパソコン/Fedora(Linux)のディスプレイ上に表示されたノートパソコン/NetBSDのPluma、xterm、Cajaですが、Fedoraのアプリケーションであるかのように利用でき、アプリケーションの起動や操作は軽快である一方、翻訳されない英語版(この場合、日本語設定をどこで行なうのか不明)が起動しました。

local_host$ ssh -X hostname
Password:
remote_host$ ls /usr/pkg/bin/gdm*
/usr/pkg/bin/gdm-control        /usr/pkg/bin/gdmflexiserver
/usr/pkg/bin/gdmXnest           /usr/pkg/bin/gdmphotosetup
/usr/pkg/bin/gdmXnestchooser    /usr/pkg/bin/gdmthemetester
/usr/pkg/bin/gdmdynamic
remote_host$ gdmflexiserver -nl
...

 また、SSHサーバ側でgdmがインストールされていれば、/usr/pkg/bin以下にgdmで始まる各種コマンドもインストールされ、gdmが起動した状態でSSHクライアントの端末で[ssh -X ssh_server]としてログインした状態から[gdmflexiserver -nl](詳細はgdmflexiserver -h参照)を実行するとSSHサーバ側のgdmがビューワXnestに表示され、セッションを選んでログインするとウィンドウマネージャやデスクトップ環境を表示させ、操作することもできます。

gdmflexiserver -nl実行/XnestでGUI表示・リモート操作
SSH X11ForwardingによるGUIリモート操作
gdmflexiserver -nl実行、Xnestで表示
SSHサーバ:NetBSD/ノートPC
SSHクライアント:LXDE/Fedora/デスクトップPC

 この画像は、デスクトップパソコン/Fedoraのディスプレイに遠隔操作でノートパソコン/NetBSDのgdmを表示したものです。

 ただ、環境の問題なのか、検証した際には、セッションを選択しようとすると、なぜか、ビューワXnest(gdmXnest)が落ちてしまい、これまた、なぜかデフォルトとなっていたOpenboxしか表示できず、原因不明ですが、何れにしてもデスクトップのリモート操作なら別途、各種VNCソフトウェアを利用した方が、よさそうです。

 自身は、当初、NetBSDもFedoraもTightVNCやTigerVNCといったVNCソフトウェアでは簡単にできたものの、何れもSSHのX11forwarding設定によるGUI操作ができなかったのですが、NetBSDをSSHサーバとしたケースについては、システム標準のxorgを使っているので本来不要なのに勘違いして[#XAuthLocation /usr/pkg/bin/xauth]をわざわざ有効にしてしまっていたことが原因と判明、一方、FedoraをSSHサーバとした場合には、相変わらず、できません。

SSHとポートフォワーディング

 ポートフォワード/ポートフォワーディング(ポート転送)とは、IPv4プロトコルにおいて任意のポートへの通信を異なるポートに転送することを可能とする仕組みです。

 これは、インターネット接続するルータにおいてグローバルIPアドレスとプライベートIPアドレスに変換するケース、サーバ専用マシン、個人所有のマシンのみから構成されるLAN上の任意のマシンはさておき、インターネット上に公開されているホストや同一ホストに複数のユーザーがアクセスし、任意のユーザーがスーパーユーザーになれる可能性のあるマルチユーザー環境のマシンなどにおいては、安全上の理由などからSSH専用ポートとして周知されているポート22を他のポートに振り替え、開けるポートを変更するようなケース、キャッシュによる高速化を目的としたプロキシにおいてHTTP専用ポート80を8080に転送するケースなどもあり、これらもポートフォワーディングの1つです。

 VNC関連の一部の操作に限っては前述のSSHのX11forwarding設定でも同様の効果はあるわけですが、時にSSHトンネルとも呼ばれるSSHとポートフォワーディングの組み合わせにおいては、任意のサービスが通信に使うポートから通信内容を暗号化し、認証を行なうSSHのポート22に転送することができ、仮に通信内容が盗聴されても解読を困難にすることができる為、より安全にサービスを利用することができるようになり、さらには、ポートフォワードによってSSHを通したいサービスのポート自体は開ける必要がない為、サーバ管理上も監視するポートが少なくて済みます。

 SSHを介す方法は、リモートホスト側から、ローカルホスト側から、更にその指定によって、一通りではありませんが、例えば、SSHを実行するSSHクライアント側でローカルホスト上の任意のポート(例local_port)とリモートホスト(例remote_host)のポート(例remote_host_port)間でポート転送する場合、次のようにします(コロンも必要)。

localhost $ ssh -N -l username -L local_port:remote_host_ip_address:remote_host_port remote_host_ip_address
Password:

 この[-N]スイッチは、SSH2で利用可能な(他の)「遠隔操作を実行しない」指定であり、このスイッチを使わないとリモートホストにログインしますが、このスイッチを付けるとログインせずにポートフォワーディング設定だけを行なうことができます。

 また、SSHサーバマシン・SSHクライアントマシン共にユーザー名が同名なら[-l username]は省略可能、名前解決済みならIPアドレス部は、ホスト名でも可です。

 ちなみに当然アクセス許可は必要ですが、SSHでは、ローカルホストとリモートホストの2台間だけでなく、ローカルホスト上で他の2台のリモートホスト間においてポート転送を設定するといったこともできます。

 例えば、VNCを例にとるとリモートホスト(192.168.0.2)においてVNCサーバをディスプレイ:1であらかじめ起動させている状態でリモートホスト(192.168.0.2)のVNCサーバ用ポート5901をsshを実行しているローカルホストの49200ポートにポート転送(ポートフォワーディング)する際には、次のようにします。

localhost $ ssh -N -l username -L 49200:192.168.0.2:5901 192.168.0.2

 VNCにおいては、ビューワやブラウザをクライアントにでき、ビューワのラッパvncviewerで以下のようにするとリモートホストの画面が、ローカルホスト上のVNCビューワに表示されます。

localhost $ vncviewer localhost:49200

 VNCを完全に終了させる場合には、sshを実行中の端末で、ビューワのみ終了させる場合は、vncviewerを実行中の端末で[Ctrl]+[c]とします。

ホーム前へ次へ