有些 SSH clients （例如: SecureCRT）允許使用者「儲存」密碼，這對系統安全是個大忌，一旦 client 遭受入侵，server 也會暴露在危險之中。

建議直接在伺服器端取消 SSH 的 password authentication 功能，改用 keyboard interactive 的方式認證，通常這樣的話，client 就無法儲存密碼了:

1. OpenSSH – /etc/ssh/sshd_config

PasswordAuthentication no
ChallengeResponseAuthentication yes

2. SSH2 (Tectia) – /etc/ssh2/sshd2_config

AllowedAuthentications          publickey,keyboard-interactive
AuthKbdInt.Optional             pam,password
AuthKbdInt.Required             password

修改好上述 sshd 的設定檔後，送個 HUP 給 sshd 即可（注意不要不小心把目前用的 session 也砍了，不然改錯的話只好到 console 前面去救了）

# ps ax | grep sbin/sshd | grep Ss
 9767 ?        Ss     0:00 /usr/sbin/sshd
# kill -HUP 9767

然後就可以請大家改用 keyboard-interactive authentication 了:

常見的 SSH Implementation 有兩種，ssh.com 的 SSH 以及 OpenSSH，詳細發展緣由可參考 OpenSSH History

由於歷史因素，所以提到 SSH 相關用語時，常因不明確而混淆。建議可以參考 O’Reilly book 出版的 SSH, The Secure Shell: The Definitive Guide 一書中對於 SSH 各種詞彙的精確定義：

Terminology: SSH Protocols and Products

SSH
    A generic term referring to SSH protocols or software products.
SSH-1
    The SSH protocol, Version 1. This protocol went through several
    revisions, of which 1.3 and 1.5 are the best known, and we will
    write SSH-1.3 and SSH-1.5 should the distinction be necessary.
SSH-2
    The SSH protocol, Version 2, as defined by several draft standards
    documents of the IETF SECSH working group.
SSH1
    Tatu Ylönen's software implementing the SSH-1 protocol; the original
    SSH. Now distributed and maintained (minimally) by SSH
    Communications Security, Inc.
SSH2
    The "SSH Secure Shell" product from SSH Communications Security, Inc.
    This is a commercial SSH-2 protocol implementation, though it is
    licensed free of charge in some circumstances.
ssh (all lowercase letters)
    A client program included in SSH1, SSH2, OpenSSH, F-Secure SSH, and
    other products, for running secure terminal sessions and remote
    commands. In SSH1 and SSH2, it is also named ssh1/ssh2, respectively.
OpenSSH
    The product OpenSSH from the OpenBSD project,
    which implements both the SSH-1 and SSH-2 protocols.
OpenSSH/1
    OpenSSH, referring specifically to its behavior
    when using the SSH-1 protocol.
OpenSSH/2
    OpenSSH, referring specifically to its behavior
    when using the SSH-2 protocol.

OpenSSH 基於相容 BSD license 的 ssh 1.2.12 來開發，後續又加上了對 SSH-2 的支援

但 OpenSSH 對 SSH-2 的實作與 ssh.com 後來對 SSH-2 的實作已經有了一些差異。

現今大部分的 open source 作業系統都已經改用 OpenSSH 了，不過有些地方還是可以看到 SSH2 的蹤跡，可能是商業版本或是非商業版本，例如:

# ssh -V
ssh: SSH Secure Shell 3.2.9.1 (non-commercial version) on i686-pc-linux-gnu

SSH Communications Security, Inc. (www.ssh.com) 的商業版本 SSH (SSH2) 正式名稱叫做 Tectia SSH client/server

熟悉 OpenSSH 的人初次接觸 SSH2 最常遇到的問題就是 Public-Key Authentication 的作法以及 Key format 都不太一樣。

OpenSSH/1 與 SSH1 的 authorization file 都是放在 ~/.ssh/authorized_keys 這個檔案之內，identity 則是放在 ~/.ssh/identity 這個檔案內

OpenSSH/2 的 authorization file 一樣是 ~/.ssh/authorized_keys，identity 則是在 ~/.ssh/id_dsa 或 ~/.ssh/id_rsa 內，依據 key type 而異。但其實因為 OpenSSH/2 有向下相容 OpenSSH/1 的功能，所以事實上也會參考 ~/.ssh/identity 來當作 SSH-1 的 identity

SSH2 就很不一樣了。SSH2 允許有多個 identity，因此會有一個檔案 ~/.ssh/identification 可以設定有哪些 identity 可用，例如:

IdKey identity-1
IdKey identity-2
IdKey identity-3

真正的 private key 放在 identity-1, identity-2, identity-3 這三個檔案內，而使用 ssh -i 指定 identity 時，不同於 OpenSSH 是直接指到 key 本身，SSH2 必須指定這個間接的 identification file

SSH2 的 public key format 也與 OpenSSH 不同，不再是一行而已，也因此 authorization file 沒辦法跟 ~/.ssh/authorized_keys 一樣一行放一個 key 值。

SSH2 也是一樣使用一個檔案來設定允許的 public key 有哪些，檔案放在 ~/.ssh/authorization

Key identity-1.pub
Key identity-2.pub
Key identity-3.pub

這個檔案表示可接受三個 public key 分別為 identity-1.pub, identity-2.pub, identity-3.pub

而如同 OpenSSH 一樣，SSH2 的 authorization 檔案內也可以指定各種 options，例如：

Key identity-1.pub
Options no-port-forwarding,no-pty
Key identity-2.pub
Options command="rsync -az --server . /home/backup-x",no-pty

詳細資訊可參考 SSH2 的 manual

SSH2 的 key format 與 OpenSSH 不同，這在兩者之間要作 public key authentication 時造成了一些麻煩。OpenSSH 提供的 ssh-keygen 可以用 -e 和 -i 兩個選項來轉換兩者的 key format:

# ssh-keygen -e -f openssh-key.pub > ssh2-key.pub
# ssh-keygen -i -f ssh2-key.pub > openssh-key.pub

OpenSSH 與 SSH2 之間的問題還不只這樣，SCP 的實作方式也不同

OpenSSH 與 SSH1 的 SCP 是 RCP over SSH，而 SSH2 附的 SCP2 背地裡則是用 SFTP 實作的，因此兩者互相 copy 東西時有時會 copy 不過去，建議還是一律改用有經過 IETF 標準認證的 SFTP 就好了

如果可以的話，全部用 OpenSSH 是最單純的，不過有時不是自己能控制的，碰到使用 SSH2 的系統，其實只要稍微了解一下差異也很容易適應就是了

參考資料:

• O’Reilly: SSH, The Secure Shell: The Definitive Guide
• SSH Public-Key Authentication
• OpenSSH – SSH.Com Interoperability

前面寫了一篇「使用 SSH 配合憑證來遠端複製檔案」
簡介使用 scp 配合 ssh 來遠端複製檔案，這樣的方式對於簡單的檔案複製是可行的，但是如果要備份大量檔案/目錄或程式，就顯得有點不太經濟了

這時候，比較好的作法是利用 rsync 配合 ssh 來運作，我們同樣使用 public/private key 的方式來認證，並限制只能作特定動作

要使用 rsync 之前，請把所有機器的 rsync 都裝起來

# cd /usr/ports/net/rsync
# make
# make install

假設我們要把 Host X 上面的目錄 /home/mysql/ 備份到 Host A 下面 /home/backup-x/ 下面，作法請先參考前一篇文章，先設好信任關係

為了方便說明，我們讓 A 去信任 X，讓 X 可以主動把檔案備份到 A 的機器上面

接下來有幾個地方要作一些修改：

1. 遠端機器 (A) authorized_keys 內的 command 要寫成


command="rsync -az --server . /home/backup-x",no-port-forwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAPWP8FS.... backup@X


2. 本機機器 (X) 的命令應該是：

rsync -az -v -e ‘ssh -i /home/backup/.ssh/id_dsa’ /home/mysql backup@A:

以上這個命令就會把 X 上面的 /home/mysql/… 備份到 A 上面的 /home/backup-x/mysql/… 了…

要注意 rsync 的語法中，來源目錄有沒有結尾的斜線 (/) 是有差異的喔，詳見 rsync 的說明

以上的作法會受限於目標目錄只能一次只能指定一個，有時間再介紹另外一種作法…

以下整理 UNIX 系統上面使用 SSH 配合憑證來遠端複製檔案

假設有一台主機叫做 X，多台要被複製檔案的機器是 A, B, C。理論上這種情況下 X 的安全等級應該要高於 A, B, C，不過這並不一定

安全等級的差異牽涉到要由哪台機器去信任哪一台機器

以 A, B, C 去信任 X 為例，作法如下：

在 X 上面用某個帳號產生一組 Private/Public Key，然後把 Public Key 發佈給 A, B, C，要求 A, B, C 去信任這一個 Public Key

更進一步，還能限制這個 Public Key 只能作某項動作…

以下是詳細的作法

[步驟一] 產生 Public/Private Key

先在 X 上面開設一個帳號，例如 backup (或者使用現有的任何一個帳號也可以) 然後使用 ssh-keygen -t dsa 命令產生一組 Private/Public Key，內定會在 .ssh/ 目錄下產生兩個檔案: id_dsa 及 id_dsa.pub (不要設定 passphrase)

由於之後會限制一組 Key 只能作特定一件工作，因此我們再執行一次 ssh-keygen -t dsa 產生另一組 Private/Public Key

記得把 Key 儲存成不同的檔名以供辨識，例如我們可以把 .ssh 目錄下的 Key 更名成:

id_cmd1 id_cmd1.pub => 用來執行命令1

id_cmd2 id_cmd2.pub => 用來執行命令2

[步驟二] 設定信任關係

接下來，我們就可以把 id_cmd1.pub 及 id_cmd2.pub 的內容複製到 A, B, C 上面了

首先在 A 上面，建立特定一個帳號，例如 backup，然後執行 vipw (FreeBSD)，把 password 欄位置換成 * 星號：

backup:*:1010:50::0:0:backup user:/home/backup:/bin/sh

這樣的話，這個帳號雖然擁有 shell，但也不能隨意用 password 來登入了，只能從 local 用 su – backup 或從遠端用 ssh public key 來進入使用

然後把 id_cmd1.pub 及 id_cmd2.pub 合成一個檔案，放在/home/backup/.ssh/authorized_keys 中:

ssh-dss AAAAB3NzaC1kc3MAAACBAPWP8FS0iatXx3z7o/alB1pI8a…. backup@X
ssh-dss AAAAB3NzaC1kc3MAAACBALW8J12p4Jebc5sAPDhiokTy2…. backup@X

這樣寫，代表 A 上面的 backup 這個帳號信任這組 public/private key，任何人持有該相對應的 private key，都可以 ssh 進入 backup 在 A 上面的帳號

既然可以 ssh，當然也可以自由使用 scp 來複製檔案了，而且使用任何一組 Key 都可以進行沒有限制的作業，

例如從 X 上面可以用 ssh 登入 A:

ssh -i /home/backup/.ssh/id_cmd1 backup@A

ssh -i /home/backup/.ssh/id_cmd2 backup@A

[步驟三] 限制只允許特定動作

由於 ssh 的權限太大，而我們只是要複製檔案 (scp) 而已，因此我們可以再作一些限制。

改寫 /home/backup/.ssh/authorized_keys，在每個 key 開頭加上特定指令，例如

command=”scp -f /tmp/backup.tgz”,no-port-forwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAPWP8FS…. backup@X
command=”scp -t /tmp/info.tgz”,no-port-forwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBALW8J12p4J…. backup@X

上面 scp -f 代表 copy 的來源， scp -t 代表 copy 的目的地，目的地也可以是一個目錄，但是要再加上 -d 選項

這樣的話，不管對方下了什麼指令，A 都只會執行前面 command 內的指令，所以…. X 只能對 A 進行下列兩種工作，而且都要指定正確的 Key 才能完成:

scp -i /home/backup/.ssh/id_cmd1 backup@A:/tmp/backup.tgz backup-A.tgz

scp -i /home/backup/.ssh/id_cmd2 data.tgz backup@A:/tmp/info.tgz

上面 scp -i 就是指定該動作要使用的身份，後面接上相對應的 private key 即可

事實上，由於每個 key 只會被對方的機器允許作特定的事情，因此遠方的目錄及檔案名稱甚至可以省略，例如:

scp -i /home/backup/.ssh/id_cmd1 backup@A: backup-A.tgz

scp -i /home/backup/.ssh/id_cmd2 data.tgz backup@A:

測試沒有問題後，把 authorized_keys 同樣複製一份到 B, C 上面就大功告成了

備註: 如果您要大量複製、備份檔案，請參考另外一篇「使用 SSH 配合憑證來遠端備份檔案 (rsync)」