❶ 加密:公鑰 私鑰什麼意思
公鑰是明文傳輸，私鑰是密文傳輸。
❷ 有沒有一種軟體能用RSA的私鑰進行加密，然後用公鑰進行解密的
如果只是單方面採用非對稱性加密演算法,其實有兩種方式,用於不同用處.第一種是簽名,使用私鑰加密,公鑰解密,用於讓所有公鑰所有者驗證私鑰所有者的身份並且用來防止私鑰所有者發布的內容被篡改.但是不用來保證內容不被他人獲得.第二種是加密
❸ ios開發rsa加密怎麼生成秘鑰
1、加密解密的第一步是生成公鑰、私鑰對，私鑰加密的內容能通過公鑰解密（反過來亦可以） 下載開源RSA密鑰生成工具openssl（通常Linux系統都自帶該程序），解壓縮至獨立的文件夾，進入其中的bin目錄，執行以下命令： 代碼如下: openssl genrsa -out rsa_private_key.pem 1024 openssl pkcs8 -topk8 -inform PEM -in rsa_private_key.pem -outform PEM -nocrypt -out private_key.pem openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem 第一條命令生成原始 RSA私鑰文件 rsa_private_key.pem，第二條命令將原始 RSA私鑰轉換為 pkcs8格式，第三條生成RSA公鑰 rsa_public_key.pem 從上面看出通過私鑰能生成對應的公鑰，因此我們將私鑰private_key.pem用在伺服器端，公鑰發放給android跟ios等前端 2、php中用生成的公鑰、私鑰進行加密解密，直接上代碼 代碼如下: $fp=fopen("rsa/rsa_private_key.pem","r"); //你的私鑰文件路徑 $private_key=fread($fp,8192); fclose($fp); $fp1=fopen("rsa/rsa_public_key.pem","r"); //你的公鑰文件路徑 $public_key=fread($fp1,8192); fclose($fp1); //echo $private_key; $pi_key=openssl_pkey_get_private($private_key);//這個函數可用來判斷私鑰是否是可用的，可用返回資源id Resource id $pu_key=openssl_pkey_get_public($public_key );//這個函數可用來判斷公鑰是否是可用的 print_r($pi_key);echo "n"; echo "<br>"; print_r($pu_key);echo "n"; echo "<br>"; echo "<hr>"; $data='php ras加密演算法'; $encrypted = ""; $decrypted = ""; echo "加密的源數據:".$data."n"; echo "<br>"; echo "private key encrypt:n"; echo "<br>"; openssl_private_encrypt($data,$encrypted,$pi_key);//私鑰加密 $encrypted = base64_encode($encrypted);//加密後的內容通常含有特殊字元，需要編碼轉換下，在網路間通過url傳輸時要注意base64編碼是否是url安全的 echo '私鑰加密後：'.$encrypted."n"; echo "<br>";echo "<br>"; echo "public key decrypt:n"; echo "<br>"; openssl_public_decrypt(base64_decode($encrypted),$decrypted,$pu_key);//私鑰加密的內容通過公鑰可用解密出來 echo '公鑰解密後：'.$decrypted."n"; echo "<br>"; echo "<hr>"; echo "public key encrypt:n"; echo "<br>"; openssl_public_encrypt($data,$encrypted,$pu_key);//公鑰加密 $encrypted = base64_encode($encrypted); echo $encrypted,"n"; echo "<br>"; echo "private key decrypt:n"; echo "<br>"; openssl_private_decrypt(base64_decode($encrypted),$decrypted,$pi_key);//私鑰解密 echo $decrypted,"n"; echo "<br>"; PHP的RSA配置常見問題： ●PHP開發語言的代碼示例中openssl文件夾中的3個DLL文件用法 1、如果你的系統是windows系統，且system32文件目錄下沒有libeay32.dll、ssleay32.dll這兩個文件 那麼需要拷貝這兩個文件到system32文件目錄。 2、如果您的php安裝目錄下（phpext）中沒有php_openssl.dll 那麼請把php_openssl.dll放在這個文件夾中 喜歡加密解密的小夥伴一定要好好看看這篇文章，受益匪淺。。。
❹ https如何進行加密傳輸
HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，TLS/SSL中使用了非對稱加密，對稱加密以及HASH演算法。握手過程的具體描述如下：
1.瀏覽器將自己支持的一套加密規則發送給網站。
2.網站從中選出一組加密演算法與HASH演算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裡麵包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
3.瀏覽器獲得網站證書之後瀏覽器要做以下工作：
a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。
b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
c) 使用約定好的HASH演算法計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。
4.網站接收瀏覽器發來的數據之後要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手消息，發送給瀏覽器。
5.瀏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通信數據將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密。
這里瀏覽器與網站互相發送加密的握手消息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密數據，為後續真正數據的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH演算法如下：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法：AES，RC4，3DES
HASH演算法：MD5，SHA1，SHA256
❺ java公鑰加密，私鑰解密，該怎麼解決
一個比較簡單的實現:一個三個類KeyGenerater生成公鑰私鑰對，Signaturer類使用私鑰簽名，SignProvider用公鑰驗證。公鑰和私鑰使用Base64加密Base64這個類也在博客裡面
public class KeyGenerater {
private byte[] priKey;
private byte[] pubKey;
public void generater() {
try {
Java.security.KeyPairGenerator keygen = java.security.KeyPairGenerator
.getInstance("RSA");
SecureRandom secrand = new SecureRandom();
secrand.setSeed("syj".getBytes()); // 初始化隨機產生器
keygen.initialize(1024, secrand);
KeyPair keys = keygen.genKeyPair();
PublicKey pubkey = keys.getPublic();
PrivateKey prikey = keys.getPrivate();
pubKey = Base64.encodeToByte(pubkey.getEncoded());
priKey = Base64.encodeToByte(prikey.getEncoded());
System.out.println("pubKey = " + new String(pubKey));
System.out.println("priKey = " + new String(priKey));
} catch (java.lang.Exception e) {
System.out.println("生成密鑰對失敗");
e.printStackTrace();
}
}
public byte[] getPriKey() {
return priKey;
}
public byte[] getPubKey() {
return pubKey;
}
}
public class Signaturer {
/**
*
* Description:數字簽名
*
* @param priKeyText
* @param plainText
* @return
* @author 孫鈺佳
* @since：2007-12-27 上午10:51:48
*/
public static byte[] sign(byte[] priKeyText, String plainText) {
try {
PKCS8EncodedKeySpec priPKCS8 = new PKCS8EncodedKeySpec(Base64
.decode(priKeyText));
KeyFactory keyf = KeyFactory.getInstance("RSA");
PrivateKey prikey = keyf.generatePrivate(priPKCS8);
// 用私鑰對信息生成數字簽名
java.security.Signature signet = java.security.Signature
.getInstance("MD5withRSA");
signet.initSign(prikey);
signet.update(plainText.getBytes());
byte[] signed = Base64.encodeToByte(signet.sign());
return signed;
} catch (java.lang.Exception e) {
System.out.println("簽名失敗");
e.printStackTrace();
}
return null;
}
}
public class SignProvider {
private SignProvider() {
}
/**
*
* Description:校驗數字簽名,此方法不會拋出任務異常,成功返回true,失敗返回false,要求全部參數不能為空
*
* @param pubKeyText
* 公鑰,base64編碼
* @param plainText
* 明文
* @param signTest
* 數字簽名的密文,base64編碼
* @return 校驗成功返回true 失敗返回false
* @author 孫鈺佳
* @since：2007-12-27 上午09:33:55
*/
public static boolean verify(byte[] pubKeyText, String plainText,
byte[] signText) {
try {
// 解密由base64編碼的公鑰,並構造X509EncodedKeySpec對象
java.security.spec.X509EncodedKeySpec bobPubKeySpec = new java.security.spec.X509EncodedKeySpec(
Base64.decode(pubKeyText));
// RSA對稱加密演算法
java.security.KeyFactory keyFactory = java.security.KeyFactory
.getInstance("RSA");
// 取公鑰匙對象
java.security.PublicKey pubKey = keyFactory
.generatePublic(bobPubKeySpec);
// 解密由base64編碼的數字簽名
byte[] signed = Base64.decode(signText);
java.security.Signature signatureChecker = java.security.Signature
.getInstance("MD5withRSA");
signatureChecker.initVerify(pubKey);
signatureChecker.update(plainText.getBytes());
// 驗證簽名是否正常
if (signatureChecker.verify(signed))
return true;
else
return false;
} catch (Throwable e) {
System.out.println("校驗簽名失敗");
e.printStackTrace();
return false;
}
}
}
望採納，謝謝。
❻ 關於公私鑰、各種證書、https基本概念掃盲
最近實習需要寫一些生成證書的腳本，藉此機會順便搞清楚了許多關於證書這塊的疑惑。說到這一塊東西，名詞多到爆炸，對稱加密、非對稱加密、密鑰、密鑰庫、公鑰、私鑰、CA、證書、數字簽名、ssh、https、ssl、keytool、openssl、PKCS、X.509以及令人眼花繚亂的文件後綴名，cer、crt、pem、keystore、jks、key、p12、pfx...
先聽我講個故事，這次我們不用Bob和Alice,聽完之後再去看這些概念，絕壁恍然大悟。
故事背景: 這是2018年，為了能夠安全的進行通信，假設每個人都有倆把鎖，一個叫A鎖，一個叫B鎖，這倆把鎖和一般的鎖有點區別，每把鎖上即帶有自己的鎖孔又帶有另一把鎖的鑰匙，因此A鎖和B鎖既是鎖又是鑰匙。 A鎖和B鎖唯一配對，A鎖鎖住之後，只有B鎖可以打開，同樣B鎖鎖住之後，只有A鎖可以打開 。其中一把鎖是公開的，而一把鎖則自己保管，不公開。假設默認A鎖是公開的，B鎖是私有的。
故事內容: 阿里巴巴子弟小學的小明想給隔壁班的小花寫封表白信，為了不被別人看到，他將信放入在信箱中，並用小花的A鎖將信箱鎖住，因為小花的B鎖(同是A鎖的鑰匙)只有小花自己有，所以除了小花以外的任何人拿到信件，都無法看到信件內容。同樣小花要給小明寫信，那麼也要用小明的A鎖對信件內容進行保護。
小明與小花通過就這樣聊了有一段時間，後來小花覺得差不多了，可以進入秀恩愛的階段了，跟小明說，以後寫信別tm加密了，又不是銀行卡密碼，被人看到又能怎麼樣呢？只要看了之後別瞎改就行了。於是小明在寫完信後，把信里每個字的拼音首字母拼湊了一個字元串，並取名為 消息摘要 ，然後僅僅將消息摘要放入信箱，用自己的B鎖鎖住這個信箱。雖然信件本身沒有放入安全的信箱，但小明作為一個情書高手，隨便一封信都是上萬字，如果其他人對信件內容做任何改變，那麼拼音首字母組成的字元串幾乎肯定會改變，因此小花拿到信件後，先用小明的A鎖(B鎖的鑰匙)打開信箱，拿到小明的摘要,然後小花再對信件內容做同樣的處理(即計算信件每個字的拼音首字母，實際上不會用這么簡單的演算法，而是會用不可逆的hash演算法)，計算出的字元串值如與小明的信息摘要一致，說明這封信就是小明寫給自己的，沒有被任何人篡改。
故事高潮: 事情並沒有那麼簡單，小花發現小明只是在信件里對自己熱情似火，平常見了面連聲招呼都不打，一副不認識的樣子。終於有一天小花忍不住了，當面質問小明，小明卻說，我什麼時候給你寫情書了，自作多情吧...於是小花把昨天剛收到的情書狠狠甩在了小明臉上:「上面落款不是你小明嗎？怎麼了,慫了？」小明一看上面還真是自己的名字，但是自己寫沒寫信自己還不知道嗎？小明把自己的作業本拿給小花，並叫自己的同桌做筆跡鑒定，小花發現筆跡的確不大像，看來是有人惡作劇，冒充小明給自己寫情書，哎，好尷尬啊。。。
故事講完了，文章開頭涉及的所有概念都與信息的安全傳輸有關，可以說，一切都是為了安全。關於通信安全，我們通常有三個基本的需求
我們以上面的故事為例說一下這三點安全需求，一開始小明與小花通過A鎖( 對應公鑰 )加密,B鎖( 對應私鑰 )解密的通信方式即符合第一點，信件內容本身被加密，而因為公私鑰唯一配對，只有配對的密鑰才可以解密，因此很難被第三人破解。
之後，為了秀恩愛，他們採用了B鎖( 私鑰 )加密，A鎖( 公鑰 )解密的通信方式，其中用私鑰對消息摘要加密後的字元串稱為 數字簽名 ,這樣雖然信件可以被人直接看到，但如果被人篡改掉後可以輕易發現數據被篡改。本來以為滿足第一條和第二條就可以安全的通信了，但最後才發現小明根本不是小明！為什麼會出現這樣的問題？因為「小明」說他是小明，小花就以為他是小明，他沒有提供任何證明自己真的是小明的認證。因此要想安全通信，我們還需要一個權威第三方的機構來做身份認證,這個機構就是CA機構，通過認證後，CA機構會頒發權威的證書，而有了證書就可以證明身份，就不會出現身份被假冒的情況。而認證的過程則需要向CA機構提供自己的身份信息以及私鑰。
對稱加密就是通信雙方或多方採用的密鑰是一樣的。加解密速度快，但不夠安全。因為一旦密鑰泄露，誰都可以對數據進行解密。非對稱加密就是當然就是通信雙方使用的密鑰不同。而公鑰和私鑰就是非對稱加密的一種方式。比較常用的對稱加密演算法如
AES、DES，非對稱加密比較常見的則有sha256,RSA。
非對稱加密演算法有倆個密鑰，一個公鑰，一個私鑰。公鑰和私鑰必須配對出現，一對公鑰和一個私鑰統稱為一個 密鑰 ，而 密鑰庫 中可以存放多個密鑰，即多對公私鑰。
如果你用github的話，應該注意到github鏈接有倆種方式。一種是https,一種是ssh,通過https經常需要輸密碼，而通過ssh則不需要。回憶你設置ssh的步驟，本地生成了一個密鑰對，並將公鑰上傳到了github。每次傳輸用自動本地私鑰加密，伺服器用你上傳的公鑰解密，就不需要手動輸入密碼了。
keytool和openssl是倆個證書管理工具.keytool是java JDK自帶的證書管理工具，使用keytool可以生成密鑰，創建證書。只要裝了jdk,並正確設置了環境變數，就可以之間通過命令行執行keytool命令來管理證書。
openssl則是一個開源的安全套接字層密碼庫，功能比keytool更加豐富。
PKCS全稱Public-Key Cryptography Standards 即公鑰標准，PKCS已經發布了15個標准。
PKCS#12 包含了公鑰和私鑰的二進制格式的證書形式，以pfx作為證書文件後綴
X.509 則是一個通用的證書標准，規定了證書應該包含哪些內容，X.509通常有倆種編碼方式，一種是二進制編碼，另一種是base64編碼
X.509#DER 二進制格式證書，常用後綴.cer .crt
X.509#PEM 文本格式證書，常用後綴.pem
因為http是明文傳輸，非常不安全，因此又提出了ssl(Secure Sockets Layer即安全套接字)層協議，即在原來的基礎上又加了一層協議用於保障安全傳輸,可以認為https=ssl+http。很多人剛開始接觸https，用瀏覽器F12打開控制台後。可能發現數據仍然沒有加密。要注意https是 傳輸層加密 ，瀏覽器F12控制台你看到的還是應用層的數據。
因為本文主要是概念掃盲，幫助理解，因此關於這部分具體細節不作介紹。
.keystore和.jks和.truststore都是java用來存放密鑰的文件
.key nginx中私鑰文件
而不同的證書文件後綴都是為了區分不同種類的證書的，主要有倆個分類維度
❼ 四、公鑰和私鑰，加密和數字簽名
本文涉及到支付寶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的， 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成 。
假設我們服務端收到了來自支付寶服務端的支付結果，即： 支付結果+數字簽名 。
那麼我們服務端就會對支付結果進行驗簽，怎麼個驗法呢？
❽ SSH詳解-3.密鑰登陸
SSH詳解-1.ssh基礎知識
SSH詳解-2.ssh基本用法
SSH詳解-3.密鑰登陸
SSH詳解-4.多個ssh公鑰
在上一篇中我們了解到了ssh基本用法，ssh通過密碼進行登錄。密碼登錄存在很多問題。密碼太簡單，又不安全。密碼太復雜，不容易記，而且每次登錄都要輸入很麻煩。於是就有了密鑰登陸。
什麼是密鑰(key)？
ssh密鑰登錄採用的是 非對稱加密 。
非對稱密鑰加密系統，又稱公鑰密鑰加密。它需要使用不同的密鑰來分別完成加密和解密操作，一個公開發布，即公開密鑰（public key）和，另一個由用戶自己秘密保存，即私用密鑰（private key）。
如果數據使用公鑰加密，那麼只有使用對應的私鑰才能解密，其他密鑰都不行；反過來，如果使用私鑰加密（這個過程一般稱為「簽名」），也只有使用對應的公鑰解密。
了解完密鑰後，接下來看看密鑰登錄的過程，SSH 密鑰登錄分為以下的步驟。
第零步，准備步驟客戶端通過 ssh-keygen 生成自己的公鑰和私鑰，並將公鑰放入遠程伺服器的指定位置。
第一步，用戶客戶端向伺服器發起SSH登錄的請求。
第二步，伺服器收到用戶SSH登錄的請求，伺服器生成一些隨機數據發送給客戶端。
第三步，客戶端接收到伺服器發過來的數據，客戶端使用私鑰對數據進行簽名後再返回給伺服器。
第四步，伺服器收到客戶端加密後的數據，使用對應公鑰進行解密。然後判斷解密後的數據是否與原始數據一致，如果一致就允許用戶登錄。
ssh-keygen 是OpenSSH提供的一個命令行工具，用於生成密鑰登錄所需的公鑰和私鑰。
在上面的例子中，我使用了-t參數來指定加密演算法，一遍會選擇rsa或者dsa。
第一個問題，問我要保存在哪？（直接Enter默認會保存在~/.ssh/id_rsa中）因為我之前已經生成過密鑰了，我就保存在tenxun裡面。
第二個問題，詢問是否要為私鑰文件設定密碼保護（passphrase）。這樣的話，即使入侵者拿到私鑰，還是需要破解密碼。如果為了方便，不想設定密碼保護，可以直接按回車鍵，密碼就會為空。
最後，就會生成私鑰和公鑰，屏幕上還會給出公鑰的指紋，以及當前的用戶名和主機名作為注釋，用來識別密鑰的來源。
從上面的公鑰中我們可以看到末尾的公鑰注釋 23696@DESKTOP-GKRBCVI
公鑰注釋可以用來識別不同的公鑰，表示這是哪台主機（DESKTOP-GKRBCVI）的哪個用戶（username）的公鑰。
注意 ，公鑰只有一行。因為它太長了，顯示的時候可能自動換行了。
OpenSSH 規定，用戶公鑰保存在伺服器的 ~/.ssh/authorized_keys 文件。你要以哪個用戶的身份登錄到伺服器，密鑰就必須保存在該用戶主目錄的~/.ssh/authorized_keys文件。只要把公鑰添加到這個文件之中，就相當於公鑰上傳到伺服器了。每個公鑰占據一行。如果該文件不存在，可以手動創建。
-i 指定要上傳公鑰（公鑰文件可以不指定路徑和 .pub 後綴名），user是所要登錄的用戶名，hostname是主機名，這兩個參數與ssh 登錄命令是一致。
特別注意 ，不是把公鑰上傳上去就行了，還需要把 authorized_keys 文件的許可權要設為644，即只有文件所有者才能寫。如果許可權設置不對，SSH伺服器可能會拒絕讀取該文件，導緻密鑰登錄失效，登錄的時候還需要輸入密碼。
提到輸入密碼，如果再生成公鑰和私鑰的時候設置了密碼，使用密鑰登錄的時候也需要輸入私鑰的密碼，這樣可以防止他人非法竊取了私鑰。
私鑰設置了密碼以後，每次使用都必須輸入私鑰密碼，這個問題可以使用 ssh-agent 命令解決。
網路-密鑰
Git - 生成 SSH 公鑰 (git-scm.com)
ssh(1) - OpenBSD manual pages
❾ 怎麼在ios進行rsa公鑰加密，java做rsa私鑰解密
1、用公鑰加密，用私鑰解密。
2、給別人發信息，就從伺服器上拉下來別人的公鑰，加密後發給他。
3、對方拿到信息後用自己的私鑰解密。
4、這樣，公鑰加密後除了私鑰持有人，別人都看不到信息。
5、若是用私鑰加密，那麼公鑰都能解密，還有何安全性可言？
6、私鑰加密的場合只有一個，那就是數字簽名，用來表明這個信息來源於你。