您好,登錄后才能下訂單哦!
openssl是一個條件實現了上百種算法、實現了單向加密工具等一組套件,代碼量很小但是功能強大。它有三部分組成:
libcrypto:通用功能的加密庫,軟件開發時可以直接調用
libssl:實現TLS/SSL的功能
openssl:多功能命令行工具,加密、解密、創建CA、證書、一對秘鑰等
openssl enc加密解密命令:
參數 | 說明 |
-des3 | 是指定加密算法 |
-a | 是輸出文件按base64內容輸出,否則就是二進制的 |
-in | 要加密的文件 |
-out | 加密后的文件 |
-salt | 加鹽 |
-d | 表示解密 |
我們建立一個文件進行加密,源文件為
openssl enc -des3 -a -salt -in /work/aaa.txt -out /work/aaa.enc
輸入兩次密碼
解密剛才的文件
openssl enc -d -des3 -a -salt -in /work/aaa.enc -out /work/aaa.out
openssl單向加密:
常見的有md5、sha1、sha256等,系統本身有這些工具如下圖:
我們現在用openssl dest命令來實現
openssl dgst -md5 FILE
openssl非對稱加密:
一般私鑰用來加密公鑰用來解密,但是如果要做電子簽名那么就需要用私鑰進行加密,公鑰進行解密。最常用的是RSA。再次說明公鑰不會用來進行數據加密因為速度太慢,通常用來秘鑰交換和身份驗證。
數字簽名:
公鑰加密私鑰解密,我們知道數字簽名不會用公鑰加密數據本身,而是加密數據的特征碼。常用算法RSA、DSA(只能用來做簽名無法做加密)。簽名本身還是加密,所以這就是說明DSA只能用公鑰加密私鑰解密,不能反過來。而RSA則可以。
數字證書:
為了保證公鑰來源的可靠性。A有CA的公鑰,B向CA申請證書且證書(里面包括B的公鑰和B的信息)中包含CA的電子簽名(CA私鑰加密的),B把證書發給A,A用CA的公鑰可以解密電子簽名來驗證有效性。證書格式包括:x509等。該證書里的內容包含申請者的公鑰、證書過期時間、申請者的合法身份信息(地址、國家、機構名稱等)、證書使用方式、CA的信息、CA的數字簽名(CA私鑰加密的證書前4項信息的摘要信息)
我們知道在訪問電子商務網站或者銀行網站的時候都是輸入一個域名,你如何知道你訪問的這個網站就是那個真正的網站而不是別人偽造的呢?這就是用到了ssl,這個網站都是綁定了證書,你輸入的域名則包含在證書中的申請者合法身份信息中。由于客戶端信任國際主要CA機構,所以為了讓客戶端也信任他要訪問的網站,那么網站所屬公司都要去CA申請證書,那私鑰和公鑰是誰生成的?顯然這一對而私鑰和公鑰是申請者自己生成的(你不可能讓CA給你生成,因為CA如果生成的話那就意味著CA擁有了你私鑰),然后把公鑰和其他必要信息發給CA,CA審核通過則頒發證書。所以你申請證書需要做的是:
自行生成一對私鑰和公鑰
把公鑰和域名等其他必要信息按照固定格式填寫并提交給CA
在以后的通訊中客戶端訪問網站的時候會獲取該網站的證書,然后去驗證合法性、之后還會查看有效期、最后還會去找CA查看該證書是否被吊銷了,都檢查過了以后才能安全的訪問。
我們知道openssl可以生成公鑰和私鑰也可以建立CA,我們就從這兩個方面來進行演示。兩臺機器
Linux01為服務器端--CA服務器
Linux02為客戶端--申請證書
演示:建立CA
如果你是在企業內部小范圍應用,可以使用這個工具來建立自己的CA然后給自己的服務器發放證書并管理吊銷列表等操作。
構建私有CA的配置文件在/etc/pki/tls/openssl.cnf,一般無需修改,但里面的一些配置要了解。
參數 | 說明 |
dir | 如果想把openssl做成CA,那么這個CA的工作目錄是哪里 |
certs | CA簽發的證書放在這里,默認是相對于CA的工作目錄下面的 |
crl_dir | CA吊銷的證書列表放在那里 |
database | 索引文件數據庫,自動生成這個文件,你通過這個文件可以快速查看有哪些證書 |
new_certs_dir | 剛剛簽署的證書放在哪里 |
certificate | CA自己的證書在哪里,這里是公鑰 |
serial | 當前序列號,CA簽發證書的編號 |
crlnumber | 吊銷證書的序列號 |
crl | 當前正在使用的CRL,證書吊銷列表文件 |
private_key | CA自己的私鑰 |
RANDFILE | 隨機數據文件 |
進入工作目錄/etc/pki/CA,生成私鑰對
通過這個命令生成私鑰,公鑰是通過從私鑰中提取而來的。私鑰的名字要和配置文件中的一樣
openssl genrsa -out ./private/cakey.pem 2048 #修改權限,不是必須的,只是為了安全。 chmod 600 ./private/cakey.pem
生成證書,openssl req是一個證書申請工具,同時也可以自簽名自己的證書
參數 | 說明 |
-in FILENAME | 輸入文件,但是通常我們用-key |
-key FILENAME | 指定私鑰文件,它會自己從私鑰文件中抽取出公鑰 |
-days N | 有效期限 |
-x509 | 自簽名時使用的證書格式,只有自簽名證書時采用 |
-out FILENAMEA | 證書放哪里,只有自簽名證書時采用 |
-new | 用于一個新申請 |
openssl req -new -x509 -key ./private/cakey.pem -out cacert.pem -days 3655
cacert.pem這個也是上面那個配置文件中定義的。執行命令會開始一個向導,輸入必要信息。這個信息也可以在上面那個文件中后半部分進行定義,這樣就不用每次都輸入了。
生成缺少的3個基本文件serial、index.txt、crlnumber,創建三個文件
touche ./index.txt serial crlnumber #有可能需要的是index.txt.attr這個文件,曾經遇到過,所以你也建立一個。
初始化serial文件,你寫00也行,因為頒發證書總要有一個序號標記。
echo 01 > serial
到此CA構建完畢
演示:生成公鑰和私鑰對兒
我們這里演示給Nginx上的站點申請證書為例,這個證書要放在Nginx的目錄中,我這里就建立一個certs的目錄,然后申請證書。這個名字我叫做nginx.pri,其實名稱無所謂,長度我使用1024.
openssl genrsa -out ./nginx.pri 1024
生成證書請求
openssl req -new -key ./nginx.pri -out new_cacert.req
我們把生成的請求文件拷貝到CA服務器上,我這里放/tmp下了,其實放哪里都一樣,最后你也要使用命令簽署這個請求。
scp new_cacert.req 172.16.100.29:/tmp/
簽發證書(在CA服務器上執行),然后就可以把證書拷貝會客戶端服務器上
openssl ca -in /tmp/new_cacert.req -out /tmp/nginx.crt -days 3655
SSL/TLS:
https其實就是引入了ssl或者tls。它是如何工作的呢?TCP/IP協議有四層,這四層中沒有一層是加密的,那如何實現http的安全通信呢?就是在應用層和傳輸層中間增加了半層,它不是一整層,因為不是所有應用都需要加密,你如果增加一整層的話那所有的都加密了。
SSL是網景公司研發的,在它的瀏覽器和WEB服務器之間實現安全通信,它叫做安全套接子層,套接字本身就是應用層程序在內核注冊的,所以在應用層和傳輸層中間增加了半層里面包括SSL庫,如果程序調用這個庫,就能夠實現安全通信了。
TLS是標準化組織仿照SSL開發的,叫做傳輸層安全,它的機制和SSL很像,只是有些東西有變化。TLSv1和SSLv3很接近,實際應用也是常用這個2個版本。
所以應用層協議調用SSL或者TLS的就是安全通信,比如http調用后變成了https等。下面說一下最常用的https是如何實現的:
場景前提是你第一次訪問淘寶網站,你要確保你訪問的是真淘寶而不是仿造的,而且要保證通信是加密的安全的。
客戶端打開瀏覽器輸入淘寶網站
DNS域名解析,當得到IP地址后與該IP進行通信
和給定IP進行通信,此時將進行TCP三次握手建立會話。下面開始SSL握手
TCP連接建立之后,瀏覽器發起HTTPS請求,將自己支持的加密規則發送給網站,網站從中選擇一組加密方式和HASH算法,然后把網站證書(證書包含公鑰、數字簽名和其他信息)發送給瀏覽器
瀏覽器查詢證書頒發機構是否自己信任的CA機構,如果在就用CA的公鑰解密證書獲取證書的數字簽名,如果成功解密說明證書來源可靠,然后查看證書有效期,之后去互聯網上的CA查詢該證書是否被吊銷,如果上述任何一項沒有通過就會得到一個提示,如果通過在地址欄就會出現一個綠色的鎖的標志。(身份驗證)
如果受信任或者用戶主動選擇信任,那么瀏覽器會生成隨機密碼,并用網站證書中的公鑰進行加密(秘鑰傳遞,瀏覽器生成的密碼是對稱加密用于加密通信數據)
瀏覽器使用之前約定好的HASH信息計算握手信息得到信息摘要,然后用生成的隨機密碼對握手信息進行加密,然后把摘要+加密后的握手信息+網站公鑰加密后的密碼發送給網站(信息加密、數據一致性)
網站收到加密后的信息,用自己的私鑰解密,得到密碼。然后用密碼解密握手信息,然后把瀏覽器發來的HASH值和自己根據握手信息計算出來的HASH值對比看是否一樣,如果一樣證明沒有被篡改。
網站使用同樣的方式來加密握手信息發送給瀏覽器
SSL握手結束,開始SSL數據傳輸,之后所有傳輸的數據都是通過瀏覽器之前生成的那個密碼來進行加密的。
注意:服務器是一般是不會驗證客戶端證書的,因為除非特殊情況,否是客戶端都要安裝客戶端證書讓服務器去驗證。l另外為了避免遭到暴力破解,SSL會話有持續時間,超過這個時間沒有請求,則自動斷開,如果再想連接,則重復上述過程。
Telnet和SSH:
早期實現遠程登錄使用Telnet,服務器支持客戶端在本地建立遠程連接會話,把本來應該在服務器上顯示的虛擬終端延伸至客戶端來顯示,早期都是物理終端,一個物理終端對應一個顯卡接口和與之對應的鍵盤,多個用戶連接就需要多個用這樣的物理終端,后來就有虛擬終端,也就是只有一個顯示器和顯卡,但是可以顯示多個登錄界面,但是服務器多了不可能登錄的時候都跑到服務器前去打開這個終端,所有就有了遠程登錄,在服務器上運行一個軟件,監聽在某一個端口,用來等待客戶端登錄連接,你要讓一個用戶可以看到登錄界面輸入用戶名和密碼就必須的關聯到用戶使用的終端上,我們知道登錄界面是login的程序,它必須關聯到用戶的界面上才能完成,用戶界面通常是一個設備,而這個設備就是一個終端設備,如果是物理終端很好解決,但是遠程主機怎么辦?把遠程主機的鼠標、鍵盤和顯示器關聯到服務器上,由服務器解析為本地登錄設備。所有就有Telnet,但是它的傳輸是明文,很不安全。所有就有了ssh,這個叫做Secure Shell的縮寫,它監聽在22號端口。
在使用SSH的場景中,通常需要使用證書,但是也不是必須的,如果沒有證書如何保證你登錄的服務器就是你要登錄的服務器呢,你SSH登錄的時候,第一次會得到一個提示,里面包含服務器的指紋信息,然后詢問你是否信任這個計算機,如果你輸入了YES,那么這個服務器的指紋信息就會記錄到你本機的一個列表中(know_hosts文件)下次就不沒有提示了。這就相當于是你手動的信任了這個主機,所有沒有證書也可以。如果有證書就不需要手動信任了。但是過了這個階段后面你就要輸入用戶名和密碼進行驗證,這個信息如何加密呢?其實在你看到輸入登錄信息之前,ssh客戶端和服務器就進行了加密方法的協商,客戶端生成一個一次性對稱加密秘鑰,然后用服務器的公鑰進行加密發送給服務器,完成秘鑰交換,然后客戶端用加密秘鑰加密用戶名和密碼信息發送給服務器,服務器用私鑰解密得到信息后進行驗證。之后彼此通信就用這個密碼。但是ssh和https不同,https通信時候一段時間沒有請求就會斷,但是ssh則不會它會一直在線,但是這就有個問題,因為不自動斷開所以如果別人捕獲了你的通信進行暴力破解,一旦成功,那么它就可以使用這個密碼。那怎么解決這個問題呢?很簡單,隨時換密碼,也就是隔一段時間協商更換一次密碼,但是連接不斷開。在Linux上基于ssh這種協議實現的軟件是openssh。
ssh認證機制:基于口令和基于秘鑰,通常使用基于秘鑰的。它需要的也很簡單
客戶端在本地生成一對兒秘鑰,其實就一個私鑰,公鑰是從私鑰中提取的,只不過ssh會自動幫你提取的。
客戶端將公鑰復制到服務器上的,要登錄的用戶的家目錄下面的.ssh目錄中authorized_keys或者authorized_keys2文件中
#生成秘鑰對,保存在用戶家目錄中的.ssh目錄中,會生成2個文件,id_rsa是私鑰id_rsa.pub是公鑰 ssh-key -t rsa
說明:上面的密碼要設置為空呢?這個密碼是給私鑰設置的,為了保護私鑰文件,所以要設置密碼,但是如果你這里設置密碼的話每次使用這個私鑰都得輸入密碼,比如當你ssh連接目標主機的時候,會用到你這個私鑰,這時候你還得輸入密碼。所以要么不加密,要么讓進程記住這個密碼,比如ssh-add或者ssh-agent它會記錄這些密碼然后一個一個常識。
復制秘鑰到遠程主機
ssh-copy-id -i 公鑰文件 用戶@主機IP
注意:這里的user是你想以哪個用戶登錄,實際上這個命令就是把公鑰文件內容寫入到目標主機的root用戶家目錄下的.ssh目錄中的authorized_keys文件中。
openssh的服務器端程序是sshd,這里說一下它的配置文件和腳本:
配置文件:/etc/ssh/sshd_config
服務腳本:/etc/rc.d/init.d/sshd
腳本配置文件:/etc/sysconfig/sshd
參數 | 說明 |
Port | 默認是22 |
ListenAddress | 監聽地址,默認是所有 |
Protocal | 協議版本,默認是2 |
HostKey | 是主機秘鑰,本機know_host里面存放的就是登錄過這臺主機的公鑰,比如A登錄B,那么A的know_host里面就會存放B的公鑰,公鑰存放位置是/etc/ssh/ssh_host_rsa_key,默認都會使用這個。 |
KeyRegenerationInterval | 我們知道主機雙方通信會生成一個臨時秘鑰用于進行對稱加密,這個密碼的有效期限就是這參數定義的,默認是1小時 |
ServerKeyBits | 主機秘鑰的長度 |
LoginGraceTime | 登錄寬限期,密碼提示符等待多久,如果期間沒有輸入密碼,則斷開連接。默認2分鐘 |
PermitRootLogin | 是否允許管理員登錄,默認是允許 |
StrictModes | 嚴格模式,除了驗證用戶名和密碼之外,還要看你所要登錄的服務器上是否有你使用的用戶的家目錄以及里面的權限。 |
MaxAuthTries | 認證最多嘗試次數,默認6次 |
MaxSessions | 最多會話建立個數,默認10個 |
RSAAuthentication | 是否使用RSA認證,默認是YES |
PubkeyAuthentication | 是否使用公鑰認證,默認是YES |
AuthorizedKeysFile | 驗證所使用的文件,默認是.ssh/authorized_keys,這個文件也就是存放對方公鑰的文件。 |
RhostsRSAAuthentication no | 是否允許基于遠程主機的認證,也就是A和B主機互信,那么B的用戶都可以登錄A主機,默認是NO |
PasswordAuthentication | 是否允許輸入密碼來進行認證,默認是YES |
ChallengeResponseAuthentication | 是否啟用挑戰式握手身份認證,默認是NO |
GSSAPIAuthentication | 是否允許GSSAPI認證,默認是YES |
GSSAPICleanupCredentials | 是否清除認證過程,默認是YES |
UsePAM | 是否使用PAM認證,默認是YES |
AllowUsers | 用戶白名單,就是僅允許哪些用戶登錄 |
DenyUsers | 用戶黑名單 |
ClientAliveInterval | 客戶端活動時間間隔,也就是超時時長,單位為秒。 |
ClientAliveCountMax | 客戶端活動消息數量,客戶端收到服務器響應之前可以發送多個個命令給服務器。 |
使用SSH的最佳實踐:
僅使用SSH2版本
限制用戶登錄,使用黑白名單
配置空閑會話超時時長,也就是多久不輸入命令自動斷開。ClientAliveInterval、ClientAliveCountMax
使用iptables設置ssh服務安全訪問策略,也就是只允許哪些IP段可以訪問
更改ssh默認端口號
使用強密碼,足夠長和復雜
使用基于公鑰認證
禁止空密碼登錄,默認是則是禁止的
使用暴力破解工具自己先破解一下看看
限制ssh方法頻度
經常看一下日志,看看有沒有人進行嘗試破解
生成強密碼:
#!/bin/bash genpasswd(){ local len=$1 [ $len == "" ] && len=20 #從/dev/urandom讀取隨機數,然后送到tr中,通過-dc參數把字符刪除,然后再送到 #head -c,把里面特殊字符刪除,取前20位,在用xargs處理 tr -dc A-Za-z0-9_ < /dev/urandom | head -c $len | xargs } genpasswd
顯示用戶登錄信息
#顯示當前系統上每個用戶賬號最近一次成功登錄信息、從哪個主機登錄以及使用了哪個終端 lastlog lastlog -u 顯示指定用戶 #顯示當前登錄用戶 whoami #顯示當前系統上最近失敗登錄信息,其實就是搜索/var/log/btmp文件 lastb #顯示當前系統上最近成功登錄信息,其實就是搜索/var/log/wtmp文件 last
編譯安裝openssl以后系統提示找不到共享庫文件
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。