自分がたまに使うけどよく忘れる機能や、 新マシンで設定したら2度と変更しないような機能、 またはその他のたわごとについて。 全然使ったことない人はman見てください。
ssh_configの設定で、ファイヤーウォール越え用。
HTTP-tunnelingとvmwareを参照のこと。
ssh_configの設定で、ログイン先からさらにsshで他のマシンにログインするときに、 RSA認証をローカルのssh-agentに返事させる設定。 ファイヤーウォールの内側などで、 複数段ログインしないと行けないマシンに行く場合に、 ローカルで1回passphraseを入れるだけで次々ログインしていけて便利。
コマンドラインオプションの-Aでも同じ意味。
公開鍵・秘密鍵の鍵ペアを作るコマンド。
SSH1の場合、 ~/.ssh/identity が秘密鍵暗号で暗号化された公開鍵暗号の秘密鍵、 ~/.ssh/identity.pub が公開鍵暗号の公開鍵になります。 仕事でログイン用の秘密鍵ファイルとパスフレーズを メールで送りつけられたことがありますが、 危ないので良い子は真似しちゃだめです。
Tera TermなどWindows環境からSSHを使いたい場合も、 基本的には鍵ペアはcygwinなどでローカルで作るべきです。 フロッピーなどで移動しても構いませんが不安ですし、 秘密鍵を自分宛のメールで送ったりすると その後いくら用心しても無駄になりかねません。
SSH2の場合、ssh-keygen -t dsa などと打てばできます。 RSA社が特許を放棄した現在では、dsaとrsaの違いは謎です。 dsaの場合はid_dsaおよびid_dsa.pubが秘密鍵と公開鍵になります。
SSH2になって、OpenSSHは RSA社純正のものと異なる公開鍵フォーマットを採用した。 不便なだけでメリットが全くわからないが、 これらは簡単に相互変換できる。
$ ssh-keygen -e -f openssh-key > rsassh-key $ ssh-keygen -i -f rsassh-key > openssh-key
OpenSSHで作った鍵をPuTTYで使いたい、なんてときも役に立つかもしれない。 （試してないけど）
本家SSHでは/etc/sshd_configで 接続元アドレスの制限ができたように思うが、 OpenSSHでは省略されているようだ。 代わりに、tcp_wrappersによる制限を使っている。 /etc/hosts.allowあたりに適当に設定すれば制限可能なはずだ。
password認証の場合に各ユーザーが制限する方法はないように思う。
RSA認証ならば、~/.ssh/authorized_keys によって、 鍵ペアごとに接続元アドレスを制限できる。 以下、OpenSSHのマニュアルから。
from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
-L と -R は理解するのが難しいオプションだろう。 （man の通りなのだが） -L は、SSH での接続元のホストのあるポートへの接続を、 接続先からのあるホストのあるポートへの接続につなぎ、 -R は、SSH での接続先のホストのあるポートへの接続を、 接続元からのあるホストのあるポートへの接続につなぐ。 このとき、接続先と接続元とのフォワーディングには SSH の経路が使われるので、あやしく壁を越える原動力になる。
-Lで作ったポートにはlocalhostからしか接続できないのも注意点だ （これを忘れるとはまる）。 -gをつけることで、-Lで作ったポートにリモートから接続できるようになる。
-Rで作ったポートにはlocalhostからしか接続できない。 これを変更する方法はsshd_configで「GatewayPorts yes」と書く以外ない。 本家SSHならばクライアント側設定で変更できるようなので、 OpenSSHも何とかして欲しいところだ。
OpenSSHには「-N」というオプションがある。 SSH2でのみ使える、接続先で何のコマンドも実行しないオプションだ。 ポートフォワード専用アカウントを作るような場合には非常に重宝する。
しかしこの機能、シェルが/bin/falseだろうと何だろうと接続に成功してしまう。 ログインを禁止したいユーザーについてシェルだけ変更して アカウントを消去しないままだったりすると、 ポートフォワードだけは可能になってしまう。 このマシンがDMZだったりした場合には、 これを経由してプライベートネット内に入られてしまうかもしれない。
ポートフォワーディングを使い、 イントラ内からの操作により外部マシンでcvs updateするメモ。 以下、イントラ内部のマシンをalita、外部のマシンをgallyとして、 alitaの$HOME/.ssh/configに以下のように設定する。
Host gally-pf HostName gally FallBackToRsh no RemoteForward 20022 localhost:22
で、gallyの$HOME/.ssh/configでは以下のように書く。
Host alita-pf HostName 127.0.0.1 Port 20022 FallBackToRsh no
alitaからgally-pfにログインして、そこで cvs -d alita-pf:/home/cvs checkout project などと打てばOK。 ForwardAgentの設定がしてあれば、 cvsを実行する際のgally→alita間のSSH認証には alitaのssh-agentが返事をするので、 cvs upなどと打つだけで更新ができ、非常に楽。
DHCPでIPもらうマシン内にリポジトリがある場合とか、実は応用範囲が広い。 だが、実用的かと言われると困る。 （普通はグローバルIPを持っているマシンにリポジトリ作るよね）
root権限をもっていないけどそのマシンに SSHでログインできるようにしたいという状況では、 ユーザー権限でsshdを動かすことが可能だ。 もちろん、sshdを起動したユーザー以外ではログインできない。
ユーザー権限で sshd を立てるときのポイントは、 設定ファイルをどうするかだ。 少なくとも、独自に hostkey を作る必要がある。 （そのマシンの秘密鍵が既に存在するときでも root の持ち物だから） さらに、quiet mode にしておくと吉ではないだろうか。 というわけで
$ /usr/local/sbin/sshd -p 22022 -q -h ./my-sshd
とかなんとかでいいだろう。 加えて、sshd_config とかの指示も必要になるかもしれない。 筆者の場合は /etc/ にあるもので不満がなかったので指定しなかった。 さらに、クライアント側の .ssh/config に
Host my-sshd Hostname 192.168.1.1 Port 22022 FallBackToRsh no
などと書いておけば一見普通に使えるようになる。
SSH では、ホストの認証のために公開鍵暗号が使われている。 各ホストの公開鍵は、管理者が /etc/ 以下に特別に入れない限り、 個人のディレクトリにたまっていくが、 LAN 環境で NFS でホームディレクトリを共有しているような場合、 localhost の鍵はマシンごとに変わるために localhost の認証はできない。 すなわち、localhost に ssh で入れない （別のホストで localhost に入る度に怒られるだけのことだが）。
解決策としては、管理者に頼んで 各マシンの /etc/ に localhost のホストキーを書いてもらうことだ。 （localhost へのパケットがネットワークに流れることはないので、 localhost へ ssh してもあまり意味はないが、 ssh で rコマンドを置き換えられるようにするためにも こういう設定にしておいた方がいいと思う。 さらに localhost へは圧縮off暗号化はblowfish という設定にすればいいかも）
あ、localhostにsshなんか打つな、という意見は非常にもっともです。 自分が管理者でない場合、このような主張が一蹴されても無理はありません。 というのも、どのマシンも127.0.0.1以外の名前を持っているはずで、 その名前を使えば自マシンにsshでログインすることが可能だからです。
hanawa<y@hnw.jp>$Date: 2003-04-08 18:54:03 $