第7講傳輸層安全

第七講傳輸層安全提綱TCP/IP安全方法SSLTLSHTTPSSSHTCP/IP安全方法TCP/IP協(xié)議棧中的安全設(shè)施的相對位置Ipsec的好處是對終端用戶和應(yīng)用是透明的，能提供一種一般性的解決方案SSL或TLS都是可執(zhí)行協(xié)議軟件包的一部分，從而對應(yīng)用是透明的，Netscape進而IE都配置了SSL。大部分Web服務(wù)器都實現(xiàn)了該協(xié)議。SSL(SecureSocketLayer)SSL(SecuritySocketLayer安全套接層)最初1994年Netscape開發(fā),專門用于保護Web通訊.保護瀏覽器和服務(wù)器之間的通信,在客戶和服務(wù)器之間提供服務(wù)器鑒別、可選客戶鑒別和加密通信信道。使用TCP提供一種可靠的端對端的安全服務(wù)。版本和歷史1.0，不成熟2.0，基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology)，并在IE中支持3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS1.0(TransportLayerSecurity傳輸層安全協(xié)議,也被稱為SSL3.1)，1997年IETF發(fā)布了Draft，同時，Microsoft宣布放棄PCT，與Netscape一起支持TLS1.01999年，發(fā)布RFC2246(TheTLSProtocolv1.0)功能客戶端驗證服務(wù)器客戶段與服務(wù)器選擇彼此支持的算法服務(wù)器驗證客戶端（可選）使用公開密鑰算法產(chǎn)生共享的密鑰SSL連接建立VersionSourceDescriptionBrowserSupportSSLv2.0VendorStandard(fromNetscapeCorp.)[SSL2]FirstSSLprotocolforwhichimplementationsexist-NSNavigator1.x/2.x-MSIE3.x-Lynx/2.8+OpenSSLSSLv3.0ExpiredInternetDraft(fromNetscapeCorp.)[SSL3]Revisionstopreventspecificsecurityattacks,addnon-RSAciphersandsupportforcertificatechains-NSNavigator2.x/3.x/4.x-MSIE3.x/4.x-Lynx/2.8+OpenSSLTLSv1.0ProposedInternetStandard(fromIETF)[TLS1]RevisionofSSL3.0toupdatetheMAClayertoHMAC,addblockpaddingforblockciphers,messageorderstandardizationandmorealertmessages.-Lynx/2.8+OpenSSLSSL協(xié)議的版本SSL3.0增加了對證書鏈加載的支持。使服務(wù)器可以將自己的服務(wù)器證書和發(fā)行者的證書一起傳給瀏覽器。證書鏈的加載，使得客戶機即使沒有安裝過服務(wù)器的中間證書，也可以來驗證服務(wù)器證書的有效性，因為服務(wù)器的中間證書被放在證書鏈中一起發(fā)送給了客戶機。SSL2.0協(xié)議只適用RSA密鑰交換方式，而SSL3.0不僅支持RSA密鑰交換（在使用證書的情況下），還支持Diffie-Hellman密鑰交換（在沒有使用證書或者沒有客戶端和服務(wù)器之間通信密鑰之前的情況下。）7層模型的第4層(傳輸層）實際上在四層的上部:TCP不需要更改操作系統(tǒng)TCP提供了可靠的消息傳輸SSL協(xié)議的位置SSL協(xié)議可用于保護正常運行于TCP之上的任何應(yīng)用協(xié)議，如HTTP、FTP、SMTP或Telnet的通信，最常見的是用SSL來保護HTTP的通信。協(xié)議的使用https://與shttp://SSLArchitecture包括SSL記錄協(xié)議和三個高層協(xié)議（握手協(xié)議、密鑰更改規(guī)格協(xié)議、報警協(xié)議）SSL記錄協(xié)議對各種更高級的協(xié)議提供基本的安全服務(wù)。SSLconnectionatransient,peer-to-peer,communicationslinkassociatedwith1SSLsessionSSLsessionanassociationbetweenclient&servercreatedbytheHandshakeProtocoldefineasetofcryptographicparametersmaybesharedbymultipleSSLconnections

避免每條連接需要進行的代價高昂的新的安全參數(shù)協(xié)商過程SSL參數(shù)會話狀態(tài)參數(shù)會話標(biāo)識符：由服務(wù)器產(chǎn)生用于標(biāo)識活動的或可恢復(fù)的會話狀態(tài)的一個任意字節(jié)序列對等證書：對等的X.509V3證書壓縮方法：加密前用于壓縮數(shù)據(jù)的算法密碼規(guī)格：大塊數(shù)據(jù)加密算法，計算MAC的散列算法主密鑰：48字節(jié)的會話密鑰可恢復(fù)性：能否把會話用于創(chuàng)建新連接的標(biāo)志比特連接狀態(tài)參數(shù)服務(wù)器和客戶端隨機數(shù)：服務(wù)器寫MAC密鑰：服務(wù)器發(fā)送數(shù)據(jù)時用于計算MAC的密鑰客戶端寫MAC密鑰：客戶端發(fā)送數(shù)據(jù)時用于計算MAC的密鑰服務(wù)器寫密鑰：服務(wù)器用于加密數(shù)據(jù)、客戶端用于解密數(shù)據(jù)的密鑰客戶端寫密鑰：客戶端用于加密數(shù)據(jù)、服務(wù)器用于解密數(shù)據(jù)的密鑰初始化向量：當(dāng)CBC模式中的數(shù)據(jù)塊正在使用時，需要為每個密鑰配置一個初始化向量。之后的IV值為前一次分組密碼算法的最后一個密文分組序列號SSLRecordProtocolServicesConfidentiality機密性usingsymmetricencryptionwithasharedsecretkeydefinedbyHandshakeProtocolAES,IDEA,RC2-40,DES-40,DES,3DES,Fortezza,RC4-40,RC4-128messageiscompressedbeforeencryptionmessageintegrity消息完整性usingaMACwithsharedsecretkeysimilartoHMACbutwithdifferentpaddingSSL記錄協(xié)議每個這樣的段最大為2^14-1=16383個字節(jié)。從原始數(shù)據(jù)段到生成SSL明文分段、SSL壓縮、SSL密文（加密步驟）SSL記錄格式SSL記錄頭部包括：內(nèi)容類型（8位）--可以是修改密碼協(xié)議、報警協(xié)議、握手協(xié)議、應(yīng)用數(shù)據(jù)四種主版本號（8位）副版本號（8位）壓縮長度（16位）-以字節(jié)為單位的明文分段（壓縮分段）長度ContentTypeMajorVersionMinorVersionCompressedLengthPlaintext(optionallycompressed)MAC(0,16,or20bytes)Encrypted1(a)ChangeCipherSpecProtocol1byte(c)HandshakeProtocolType1byteLengthContent3bytes3bytes(b)AlertProtocolLevel1byteAlert1byte(d)OtherUpperLayerProtocolasTLSPayloadContentUpto214+2048bytesSSL記錄協(xié)議負(fù)載SSL修改密文協(xié)議協(xié)議由單個消息組成,該消息只包含一個值為1的單個字節(jié)。該消息的唯一作用就是使未決狀態(tài)拷貝為當(dāng)前狀態(tài),更新用于當(dāng)前連接的密碼組。為了保障SSL傳輸過程的安全性,雙方應(yīng)該每隔一段時間改變加密規(guī)范。SSL告警協(xié)議為對等實體傳遞SSL的相關(guān)警告。如果在通信過程中某一方發(fā)現(xiàn)任何異常,就需要給對方發(fā)送一條警示消息通告。警示消息有兩種

Fatal錯誤,如傳遞數(shù)據(jù)過程中,發(fā)現(xiàn)錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩沖區(qū)相應(yīng)的會話記錄;

Warning消息,這種情況,通信雙方通常都只是記錄日志,而對通信過程不造成任何影響。（對警告的內(nèi)容做了相關(guān)的約定）SSL握手協(xié)議1使得服務(wù)器和客戶能夠相互鑒別對方,協(xié)商具體的加密算法和MAC算法以及保密密鑰,用來保護在SSL記錄中發(fā)送的數(shù)據(jù)SSL握手協(xié)議允許通信實體在交換應(yīng)用數(shù)據(jù)之前協(xié)商密鑰的算法、加密密鑰和對客戶端進行認(rèn)證（可選）的協(xié)議，為下一步記錄協(xié)議要使用的密鑰信息進行協(xié)商，使客戶端和服務(wù)器建立并保持安全通信的狀態(tài)信息。SSL握手協(xié)議是在任何應(yīng)用程序數(shù)據(jù)傳輸之前使用的。SSL握手協(xié)議包含四個階段:建立安全能力;服務(wù)器鑒別和密鑰交換;客戶鑒別和密鑰交換;完成握手協(xié)議。建立安全能力服務(wù)器認(rèn)證和密鑰交換客戶端認(rèn)證和密鑰交換完成SSL握手協(xié)議細(xì)節(jié)第一階段客戶端發(fā)起建立連接請求Client_hello消息

Version：客戶端SSL的最高版本號Random：隨機序列32位時間戳+28字節(jié)隨機數(shù)（防重放攻擊），用于生成主秘密。SessionID:會話ID非零值表示用戶希望重用現(xiàn)有會話的參數(shù)；零值表示客戶端希望建立新的會話ID并協(xié)商安全參數(shù)

CipherSuite:密碼構(gòu)件，客戶端可以支持的密碼算法組合（以優(yōu)先遞減順序給出）CompressionMethod:客戶端支持的壓縮方法列表ServerHello信息Version：取客戶端支持的最高版本號和服務(wù)端支持的最高版本號中的較低者。Random：用于生成主秘密的32字節(jié)的隨機數(shù)。（客戶端一個、服務(wù)端一個）會話ID：如果client_hello中的會話ID非零，則差找相應(yīng)存儲的會話參數(shù)，反饋用原值，為零則產(chǎn)生一個新的會話ID從客戶端的密碼套件列表中選擇的一個密碼套件，若用原會話ID，則直接用相應(yīng)參數(shù)從客戶端的壓縮方法的列表中選擇的壓縮方法SSL握手協(xié)議細(xì)節(jié)密碼套件列表參數(shù)密鑰交換方法（6種：無效（沒有密鑰交換）、RSA、匿名Diffie-Hellman、EphemeralDiffie-Hellman、FixedDiffie-Hellman、Fortezza）；

塊加密算法（AES,IDEA,RC2-40,DES-40,DES,3DES,Fortezza,RC4-40,RC4-128）MAC算法（MD5，SHA-1）FixedDiffie-Hellman

公鑰證書中包含固定的Diffie-Hellman公鑰參數(shù)EphemeralDiffie-Hellman

Diffie-Hellman公鑰參數(shù)使用發(fā)送者的RSA私鑰或DSS密鑰的方式被交換和簽名，可以獲得一個臨時的被認(rèn)證的密鑰SSL握手協(xié)議細(xì)節(jié)列舉JSSE支持的幾個套件：

SSL_RSA_WITH_RC4_128_MD5=0x0004

/*非對稱加密算法或密鑰交換算法為RSA，采用高強度128位對稱加密算法RC4，摘要或MAC算法為MD5，不支持出口*/

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA=0x0014

/*非對稱加密算法或密鑰交換算法支持RSA和DH，采用40位對稱加密算法DES，摘要或MAC算法為SHA，可以出口*/

JSSE，即Java(TM)SecureSocketExtension。JSSE是基于安全算法和握手機制之上的合成體。JSSE將危險的安全弱點降到最低點，并且它減輕了開發(fā)者的負(fù)擔(dān)，使得開發(fā)者可以很輕松的整合到程序中。

SSL(SecureSocketsLayer)是JSSE中的重要的部分。OpenSSL采用C語言作為開發(fā)語言，這使得OpenSSL具有優(yōu)秀的跨平臺性能，這對于廣大技術(shù)人員來說是一件非常美妙的事情，可以在不同的平臺使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺，這使得OpenSSL具有廣泛的適用性。1998年，OpenSSL項目組接管了OpenSSL的開發(fā)工作，并推出了OpenSSL的0.9.1版，到目前為止，OpenSSL的算法已經(jīng)非常完善，對SSL2.0、SSL3.0以及TLS1.0都支持。SSL握手協(xié)議細(xì)節(jié)第二階段服務(wù)器認(rèn)證和密鑰交換證書：服務(wù)器將數(shù)字證書和到根CA整個鏈發(fā)給客戶端，使客戶端能用服務(wù)器證書中的服務(wù)器公鑰認(rèn)證服務(wù)器。服務(wù)器密鑰交換（可選）：這里視密鑰交換算法而定證書請求：服務(wù)端可能會要求客戶自身進行驗證。服務(wù)器握手完成：第二階段的結(jié)束，第三階段開始的信號SSL握手協(xié)議細(xì)節(jié)如果協(xié)商過程中確定使用RSA交換密鑰，SSL握手協(xié)議細(xì)節(jié)證書（可選）：為了對服務(wù)器證明自身，客戶要發(fā)送一個證書信息，這是可選的，在IIS中可以配置強制客戶端證書認(rèn)證。客戶機密鑰交換（Pre-master-secret）：這里客戶端將預(yù)備主密鑰發(fā)送給服務(wù)端，注意這里會使用服務(wù)端的公鑰進行加密。證書驗證（可選），對預(yù)備秘密和隨機數(shù)進行簽名，證明自己擁有證書的私鑰。SSL握手協(xié)議細(xì)節(jié)Client發(fā)送消息給服務(wù)器確認(rèn)將來客戶端將會用會話密鑰,然后客戶端發(fā)送一個消息（加密的）指示服務(wù)器客戶端握手部分結(jié)束。Server發(fā)送消息給客戶端確認(rèn)服務(wù)器端將會使用會話秘鑰,然后服務(wù)端發(fā)送一個消息（加密的）指示客戶端服務(wù)器握手部分結(jié)束。SSL握手結(jié)束，SSL會話開始。C與S使用會話密鑰來加解密相互發(fā)送的數(shù)據(jù)以及驗證消息的完整性。CryptographicComputationsmastersecretcreationaone-time48-bytevaluegeneratedusingsecurekeyexchange(RSA/Diffie-Hellman)andthenhashinginfogenerationofcryptographicparametersclientwriteMACsecret,aserverwriteMACsecret,aclientwritekey,aserverwritekey,aclientwriteIV,andaserverwriteIV

generatedbyhashingmastersecret密鑰計算過程SSL協(xié)議安全性分析鑒別機制公開密鑰技術(shù)和數(shù)字證書可以實現(xiàn)客戶端和服務(wù)器端的身份鑒別。加密機制

混合密碼體制的使用提供了會話和數(shù)據(jù)傳輸?shù)募用苄员Ｗo。雙方使用非對稱密碼體制協(xié)商出本次將要使用的會話密鑰，并選擇一種對稱加密算法。完整性機制

定義了共享的、可以用來形成報文鑒別碼MAC的密鑰。數(shù)據(jù)進行分片壓縮后，使用單向散列函數(shù)產(chǎn)生一個MAC，加密后置于數(shù)據(jù)包的后部，并且再一次和數(shù)據(jù)一起被加密,然后加上SSL首部進行網(wǎng)絡(luò)傳輸。 這樣，如果數(shù)據(jù)被修改，其散列值就無法和原來的MAC相匹配，從而保證了數(shù)據(jù)的完整性?？怪胤殴?/p>

SSL使用序列號來保護通信方免受報文重放攻擊。這個序列號被加密后作為數(shù)據(jù)包的負(fù)載。 在整個SSL握手中，都有一個唯一的隨機數(shù)來標(biāo)記這個SSL握手，這樣重放便無機可乘。SSL協(xié)議安全性分析SSL脆弱性分析客戶端假冒因為SSL協(xié)議設(shè)計初衷是對Web站點及網(wǎng)上交易進行安全性保護，使消費者明白正在和誰進行交易要比使商家知道誰正在付費更為重要，為了不致于由于安全協(xié)議的使用而導(dǎo)致網(wǎng)絡(luò)性能大幅下降，SSL協(xié)議并不是默認(rèn)地要求進行客戶鑒別，這樣做雖然有悖于安全策略，但卻促進了SSL的廣泛應(yīng)用。針對這個問題，可在必要的時候配置SSL協(xié)議，使其選擇對客戶端進行認(rèn)證鑒別。無法提供基于UDP應(yīng)用的安全保護SSL協(xié)議需要在握手之前建立TCP連接，因此不能對UDP應(yīng)用進行保護。如果要兼顧UDP協(xié)議層之上的安全保護，可以采用IP層的安全解決方案。SSL協(xié)議不能對抗通信流量分析由于SSL只對應(yīng)用數(shù)據(jù)進行保護，數(shù)據(jù)包的IP頭和TCP頭仍然暴露在外，通過檢查沒有加密的IP源和目的地址以及TCP端口號或者檢查通信數(shù)據(jù)量，一個通信分析者依然可以揭示哪一方在使用什么服務(wù)，有時甚至揭露商業(yè)或私人關(guān)系的秘密。進程中主密鑰泄漏除非SSL的工程實現(xiàn)大部分駐留在硬件中，否則主密鑰將會存留在主機的主存儲器中，這就意味著任何可以讀取SSL進程存儲空間的攻擊者都能讀取主密鑰，因此，不可能面對掌握機器管理特權(quán)的攻擊者而保護SSL連接，這個問題要依靠用戶管理策略來解決。SSL脆弱性分析磁盤上的臨時文件可能遭受攻擊對于使用虛擬內(nèi)存的操作系統(tǒng)，不可避免地有些敏感數(shù)據(jù)甚至主密鑰都交換到存盤上，可采取內(nèi)存加鎖和及時刪除磁盤臨時文件等措施來降低風(fēng)險安全盲點系統(tǒng)管理員不能使用現(xiàn)有的安全漏洞掃描或網(wǎng)絡(luò)入侵檢測系統(tǒng)來審查或監(jiān)控網(wǎng)絡(luò)上的SSL交易。加密技術(shù)使得通過網(wǎng)絡(luò)傳輸?shù)男畔o法讓IDS辨認(rèn).使得最重要的服務(wù)器反而成為受到最少防護的服務(wù)器。對此，惡意代碼檢測、增強的日志功能等基于主機的安全策略會成為最后防線。SSL脆弱性分析SSL的評價SSL仍然不失為一套全面完善的安全策略中有效的組成元素。然而，與網(wǎng)絡(luò)安全的其它工具軟件一樣，僅使用單一的防護軟件都是遠遠不夠的。對SSL的過高評價有可能帶來高的安全風(fēng)險，它僅僅是網(wǎng)絡(luò)安全工具的一種，必須和其它網(wǎng)絡(luò)安全工具緊密結(jié)合，方能構(gòu)造出全面、完善、安全可靠的網(wǎng)絡(luò)。傳輸層安全（TLS）RFC5246非常接近于SSLv3記錄格式與SSL完全相同不同消息認(rèn)證碼的計算使用了RFC2104定義的HMAC算法；而SSL也使用相同算法，只是填充部分采用了與密鑰串接的方式而不是異或方式，安全強度基本相同定義了更多的報警碼密鑰構(gòu)建細(xì)小差別TLS不支持Fortezza密鑰計算HTTPsHTTP和SSL結(jié)合實現(xiàn)網(wǎng)絡(luò)瀏覽器和服務(wù)器之間的安全通信，RFC2818HTTPS和HTTP的區(qū)別https協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。http信息是明文傳輸，https則是具有安全性的SSL加密傳輸協(xié)議。http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。HTTPs解決的問題信任主機的問題.采用https的服務(wù)器必須從CA申請一個用于證明服務(wù)器用途類型的證書。目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https的?？蛻敉ㄟ^信任該證書，從而信任了該主機。通訊過程中的數(shù)據(jù)的泄密和被篡改一般意義上的https，就是服務(wù)器有一個證書。保證服務(wù)器是他聲稱的服務(wù)器。

服務(wù)端和客戶端之間的所有通訊，都是加密的?？蛻舳水a(chǎn)生一對稱的密鑰，通過服務(wù)器的證書來交換密鑰所有的信息往來都加密

少許對客戶端有要求的情況下，會要求客戶端也必須有一個證書。除了用戶名/密碼，還有一個CA認(rèn)證過的身份。個人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤（即U盾）作為一個備份的載體。SSH（SecureShell

）一、信任主機的問題.采用https的服務(wù)器必須從CA（CertificateAuthority）申請一個用于證明服務(wù)器用途類型的證書。該證書只有用于對應(yīng)的服務(wù)器的時候，客戶端才信任此主機。所以目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https的?？蛻敉ㄟ^信任該證書，從而信任了該主機。其實這樣做效率很低，但是銀行更側(cè)重安全。這一點對我們沒有任何異議，我們的服務(wù)器，采用的證書不管是自己發(fā)布的還是從公眾的地方發(fā)布的，其客戶端都是自己人，所以我們也就肯定信任該服務(wù)器。二、通訊過程中的數(shù)據(jù)的泄密和被篡改1．一般意義上的https，就是服務(wù)器有一個證書。a)主要目的是保證服務(wù)器就是他聲稱的服務(wù)器，這個跟第一點一樣。b)

服務(wù)端和客戶端之間的所有通訊，都是加密的。i.具體講，是客戶端產(chǎn)生一個對稱的密鑰，通過服務(wù)器的證書來交換密鑰，即一般意義上的握手過程。ii.接下來所有的信息往來就都是加密的。第三方即使截獲，也沒有任何意義，因為他沒有密鑰，當(dāng)然篡改也就沒有什么意義了。2．少許對客戶端有要求的情況下，會要求客戶端也必須有一個證書。a)這里客戶端證書，其實就類似表示個人信息的時候，除了用戶名/密碼，還有一個CA認(rèn)證過的身份。因為個人證書一般來說是別人無法模擬的，所有這樣能夠更深的確認(rèn)自己的身份。b)目前少數(shù)個人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤（即U盾）作為一個備份的載體。

[protocolforsecurenetworkcommunicationsdesignedtobesimple&inexpensiveSSH1providedsecureremotelogonfacilityreplaceTELNET&otherinsecureschemesalsohasmoregeneralclient/servercapabilitySSH2fixesanumberofsecurityflawsdocumentedinRFCs4250through4254SSHclients&serversarewidelyavailablemethodofchoiceforremotelogin/XtunnelsSSH是目前較可靠，專為遠程登錄會話和其他網(wǎng)絡(luò)服務(wù)提供安全性的協(xié)議。利用SSH協(xié)議可以有效防止遠程管理過程中的信息泄露問題。SSH最初是UNIX系統(tǒng)上的一個程序，后來又迅速擴展到其他操作平臺。SSH客戶端適用于多種平臺。

幾乎所有UNIX平臺—包括HP-UX、Linux、AIX、Solaris、DigitalUNIX、Irix，以及其他平臺—都可運行SSH。SSH（SecureShell

）SSH（SecureShell

）SSHTransportLayerProtocolserverauthenticationoccursattransportlayer,basedonserver/hostkeypair(s)serverauthenticationrequiresclientstoknowhostkeysinadvance（客戶端本地數(shù)據(jù)庫保存，服務(wù)器公鑰或者CA根密鑰）packetexchangeestablishTCPconnectioncanthenexchangedataidentificationstringexchange（識別字符串交換）這些字符用于Diffie-Hellman密鑰交換,algorithmnegotiation（算法協(xié)商）給出算法清單,包括密鑰交換、加密、MAC算法和壓縮算法（p136）

keyexchange（密鑰交換）,Diffie-Hellman服務(wù)器用私鑰簽名endofkeyexchange,（密鑰生成-協(xié)商后的密鑰做hash運算）servicerequest請求獲得身份認(rèn)證usingspecifiedpacketformat（分組長度、填充域長度、壓縮的有效載荷、SSHUserAuthenticationProtocolauthenticatesclienttoserverthreemessagetypes:SSH_MSG_USERAUTH_REQUESTSSH_MSG_USERAUTH_FAILURESSH_MSG_USERAUTH_SUCCESSauthe