㈠ linux生成的rsa秘鑰在哪
方法一， 有的時候經常需要登錄ssh，每次都需要輸入密碼，會比較繁瑣。所以設置了一下使用RSA公鑰認證的方式登錄Linux。 首先需要在伺服器端設置/etc/ssh/sshd_config # vim /etc/ssh/sshd_config 修改如下兩行為yes。其實大多數情況下不用修改，默認就是yes。 RSAAuthentication yes PubkeyAuthentication yes (1) 如果客戶機和伺服器都是Linux機器，那麼我們使用下面的方法：(後面第2節會提到怎麼在Windows下使用Putty生成密鑰對) 我們需要在客戶端生成RSA密鑰對。使用ssh-keygen命令： # ssh-keygen -t rsa 參數t的意思是type，後面跟著加密類型，這里我們是rsa。 然後會提示你輸入密鑰保存完成文件名，這里我們需要使用默認的id_rsa，之後才能正常才能登錄。如果你生成的密鑰作為其他用處，那麼可以命名為其他名稱： Generating public/private rsa key pair. Enter file in which to save the key (/home/cake/.ssh/id_rsa): 之後會提示你輸入一個passphrase，我們這里可以留空，這樣我們登錄的時候就不許輸入密碼。 Enter passphrase (empty for no passphrase): Enter same passphrase again: 然後會提示你密鑰生成成功。這是你的私鑰保存為~/.ssh/id_rsa，你的公鑰是~/.ssh/id_rsa.pub 我們現在需要做的是，把id_rsa.pub的內容，添加的伺服器端的~/.ssh/autherized_keys文件最後。 你可以把這個文件上傳到伺服器端，然後使用命令： # cat id_rsa.pub >> ~/.ssh/autherized_keys 到這里就完成了。 (2) 在Windows下使用Putty生成密鑰對： Putty的安裝目錄下有個puttygen.exe程序，我們運行這個程序。 之後點擊Generate，開始生成密鑰對。我們需要根據提示，在指定方框內隨機滑動滑鼠。這是為了根據滑鼠軌跡，產生一些隨機數據。 之後生成結束，我們點擊Save Private Key將私鑰存放在某個目錄中。然後賦值最上面文本框中的全部內容，粘貼到Linux伺服器端的autherized_key的最後。 我們現在可以關閉這個小程序。 現在打開Putty，在左邊的選項中，選擇Conneciton–SSH–Auth，在Private key file for authentication中，選擇剛才保存的私鑰路徑就可以了。 到此位置，Putty也可以不用密碼登錄了。 方法二 使用Linux主機生成的密匙 1、生成密匙 [root@ .ssh]#ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: e4:9a:47:a7:b4:8a:0b:98:07:b8:70:de:6b:16:2c:0croot@ 2、將 /root/.ssh/id_rsa.pub改名為/root/.ssh/authorized_keys [root@ .ssh]#mv /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys 3、將私鑰id_rsa拷貝到遠程客戶端 1)、如果遠程客戶端是linux，拷貝到遠程客戶端/root/.ssh/即可 2)、putty作為遠程客戶端在 putty不能識別直接從伺服器拷貝來的私鑰，需要使用puttygen.exe進行格式轉換 (1)、打開puttygen.exe --> Conversions --> Import Key (2)、選擇拷貝過來的私鑰文件id_rsa (3)、Save private key->id_rsa.ppk(保存私鑰) 4、打開putty.exe 1)、Session --> Host Name (填寫伺服器地址或者域名) 2)、Connection --> SSH --> Auth (點Browse選擇剛生成的id_rsa.ppk) 3)、open 成功打開後出現如下提示： login as: root Authenticating with public key "imported-openssh-key" ---------------------------------------------------------------------------------- 當然你有可能會遇到這個錯誤 [因為我遇到了，呵呵]： Permissions 0755 for '你配置的公鑰文件路徑' are too open. 這個是因為這幾個文件許可權設置的有點問題 執行命令： chmod 600 你的文件
㈡ RSA公私鑰和簽名、驗簽過程
RSA又叫非對稱加密演算法，這類加密演算法有2個秘鑰，你可以選擇一個作為私鑰（自己保存，重要），另一個作為公鑰（對外公開，誰都可以知道）。其中用私鑰加密的內容只能用對應的公鑰解密，同理用公鑰加密的內容也只能用對應的私鑰解密。
假設A生成了一對秘鑰，私鑰自己保存，公鑰對外公開，且B獲得了A的公鑰。在A和B通信的過程中：
A向B發送信息：A用自己的私鑰加密，B可以用其公鑰解密；
B向A發送信息：B用（A給的）公鑰加密數據，A可以用自己的私鑰解密；
這樣就保證了數據的安全傳輸；但是這中間存在問題，如果B向A發送數據的過程中被C攔截了，且C也雀簡獲得了A的公鑰，這樣C就可以用緩歲兄公鑰重新加密一份數據發送給A，這樣就篡改了B發送給A的數據。為了辨別這種情況，就要說到數字簽名的作用了。
因為在數據傳輸過程中有可能被篡改，因此我們要使用數字簽名技術來校驗發送擾襲方的身份，並且事後發送方無法抵賴。這里還以A和B為例，來看下數字簽名的主要過程：
數字簽名是什麼？
㈢ 四、公鑰和私鑰，加密和數字簽名
本文涉及到支付寶SDK的內容，均摘自支付寶開放平台。
因為支付寶SDK使用RSA來加密和生成數字簽名，所以本文中涉及到的概念也都是針對於RSA的。
一對兒密鑰生成後，會有公鑰和私鑰之分，我們需要把私鑰保存下來，而把公鑰發布出去。一對兒公鑰和私鑰，不能由其中一個導出另一個。
比如使用支付寶SDK的時候，我們商戶端會生成一對兒密鑰A和B，A是私鑰，B是公鑰，支付寶也會生成一對兒密鑰C和D，C是私鑰，D是公鑰。我們商戶端需要把商戶端私鑰A保存下來，而把商戶端公鑰B發布出去給支付寶，支付寶需要把支付寶私鑰C保存下來，而把支付寶公鑰D發布出去給我們商戶端。
加密是指我們使用一對兒密鑰中的一個來對數據加密，而使用另一個來對數據解密的技術，需要注意的是公鑰和私鑰都可以用來加密，也都可以用來解密 ，並不是規定死了只能用公鑰加密私鑰解密，但是加解密必須是一對兒密鑰之間的互相加解密，否則不能成功。
加密的目的是為了保證數據的不可讀性，防止數據在傳輸過程中被截獲。
知道了加密這個概念，我們先看一下支付寶的加密過程，再引出數字簽名這個概念。接著第1小節的例子，當我們商戶端和支付寶互相發布了公鑰之後，我們商戶端手裡就有 商戶端私鑰 和 支付寶公鑰 兩個密鑰，支付寶手裡也有 商戶端公鑰 和 支付寶私鑰 兩個密鑰。現在假設我們商戶端要給支付寶傳輸訂單信息，那麼為了保證傳輸訂單信息時數據的安全性，結合我們商戶端手裡所擁有的密鑰，可以有兩套加密方案
貌似這兩套加密方案都能達到對訂單信息加密的效果，而且如果採用方案二，我們商戶端甚至只需要存儲支付寶公鑰這一個密鑰，都不用去申請一對兒商戶端的公私鑰來維護，支付寶也不用保存我們一堆商戶那麼多的商戶端公鑰了，這不是更簡單嗎，那為什麼支付寶開放平台讓我們採用的是方案一而不是方案二呢？下面來回答一下。
支付寶開放平台說明：當我們採用RSA（1024位密鑰）來加密的時候，支付寶分配給所有商戶的支付寶公鑰都是一樣的，即支付寶針對那麼多的商戶只負責維護一對兒支付寶公私鑰，這就意味著支付寶公鑰隨便什麼人拿到後都是一樣的；而當我們採用RSA2（2048位密鑰）來加密的時候，支付寶會分配給每個商戶單獨的一個支付寶公鑰，即支付寶為每一個的商戶單獨的維護一對獨立的支付寶公私鑰，當然一個商戶下的多個App的支付寶公鑰是一樣的。RSA是早就支持的，RSA2是最近才支持的。
知道了上面這段話，現在假設我們採用的是方案二，並且採用RSA加密（很多老業務並沒有使用RSA2加密），業務邏輯將會是下面這樣。
這就出問題了， RSA加密下，支付寶公鑰是公開發布的，而且所有的商戶用的都是同一個支付寶公鑰（上面聲明了RSA2加密下，支付寶才針對每個商戶維護了一對兒公私鑰），攻擊者很容易就能獲取到，而 notify_url 也很容易被截獲，那攻擊者拿到這兩個東西就可以做和商戶一樣的操作來發起支付請求，這樣就會一直給小明充錢了。
所以 支付寶就需要確認支付請求確實是商戶發給他們的，而不是攻擊者發給他們的。 這就用到了 數字簽名 ，我們會通過方案一的實現流程來引出數字簽名的具體概念。如果我們採用的是方案一，我們商戶端保存的就是商戶端私鑰和支付寶公鑰，而支付寶保存的就是需要存著商戶端公鑰和支付寶私鑰的，業務邏輯將會是下面這樣。
這樣就可以保證交易的安全性了，我們也可以看出使用支付寶SDK保證交易的安全性注重的其實不是訂單信息是否加密，而是如何確保商戶端和支付寶能夠互相確認身份，訂單信息是明文的，但是後面拼接了數字簽名。
數字簽名其實就是明文數據加密之後得到的一個密文，只不過它是用私鑰加密生成的而已，我們一般會把數字簽名拼接在明文數據後面一起傳遞給接收方，接收方收到後用公鑰解密數字簽名，從而驗證發送方的身份、以及明文數據是否被篡改。數字簽名的生成過程其實就是一個加密過程，數字簽名的驗簽過程就是一個解密過程。
數字簽名的目的有兩個：一、發送方和接收方互相驗證身份；二、驗證數據是否被篡改。
從上面第一部分我們知道為了確保商戶和支付寶交易的安全性，約定採用的是給訂單信息加數字簽名傳輸的方式。支付寶也為我們提供了 一鍵生成RSA密鑰的工具 ，可以幫助我們很快的生成一對商戶端公私鑰。以下會對支付寶SDK的支付流程做個大概的解釋，並點出實際開發中我們使用支付寶SDK時應該注意的地方。
由我們商戶端自己生成的RSA私鑰（必須與商戶端公鑰是一對），生成後要保存在服務端，絕對不能保存在客戶端，也絕對不能從服務端傳輸給客戶端。
用來對訂單信息加簽，加簽過程一定要在服務端完成，絕對不能在客戶端做加，客戶端只負責用加簽後的訂單信息調起支付寶來支付。
由我們商戶端自己生成的RSA公鑰（必須與商戶端私鑰是一對），生成後需要填寫在支付寶開放平台。
用來給支付寶服務端驗簽經過我們加簽後的訂單信息，以確保訂單信息確實是我們商戶端發給支付寶的，並且確保訂單信息在傳輸過程中未被篡改。
這個和我們就沒關系了，支付寶私鑰是他們自己生成的，也是他們自己保存的。
用來對支付結果進行加簽。
支付寶公鑰和支付寶私鑰是一對，也是支付寶生成的，當我們把商戶端公鑰填寫在支付寶開放平台後，平台就會給我們生成一個支付寶公鑰，我們可以復制下來保存在服務端，同樣不要保存在客戶端，並且不要傳輸給客戶端。
用來讓服務端對支付寶服務端返給我們的同步或非同步支付結果進行驗簽，以確保支付結果確實是由支付寶服務端返給我們服務端的，而且沒有被篡改，對支付結果的驗簽工作也一定要在服務端完成。
上面已經說過了： 訂單信息的加簽和支付結果的驗簽是一定要在服務端做的，絕對不能在客戶端做。
下面是在客戶端對訂單信息加簽的過程，僅僅是為了模擬服務端來表明訂單信息是如何通過加簽最終轉變為orderString的， 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成 。
假設我們服務端收到了來自支付寶服務端的支付結果，即： 支付結果+數字簽名 。
那麼我們服務端就會對支付結果進行驗簽，怎麼個驗法呢？
㈣ RSA 公鑰和私鑰
首先明確一點，公鑰和私鑰是成對出現的。一個負責加密，另一個負責解密。公開的就是公鑰，自己留著的就是私鑰。所以不管加密還是解密密鑰都是可以是公鑰或者私鑰的。
所以如果別人發東西給我，我就需要把加密密鑰給別人，解密密鑰自己藏著，這樣就是公鑰加密，私鑰解密。
如果我想讓別人確認我的身份，我就需要把解密密鑰給別人，加密密鑰自己留著，給自己加密，別人獲得密文後用我的解密密鑰才可以解密。所以這里就是公鑰負責解密，私鑰負責加密。
例如伺服器證書，一個證書中通常包含很多欄位，其中包括：
瀏覽器收到證書時會對簽名頒發機構進行檢查。如果這個機構是個很有權威的公共簽名機構，瀏覽器可能已經知道其公開密鑰了（瀏覽器會預先安裝很多簽名頒發機構的證書），然後用公鑰解密，獲得相關信息，例如獲得證書裡面的Web站點的名稱和主機名，看看與當前瀏覽器的地址欄中的地址是否匹配，不匹配的話，瀏覽器就會給出警告（你可能看到過），提示當前證書是頒給xxx域名的，不是給當前域名的，讓你注意。