セキュアシェル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
セキュアシェル
プロトコルスタック
目的安全な接続、リモートアクセス
開発者TatuYlönen、インターネットエンジニアリングタスクフォース(IETF)
序章1995年
OSI層アプリケーション層を介したトランスポート層
ポート22
RFC(s)RFC 4250、RFC 4251、RFC 4252、RFC 4253、RFC 4254

Secure Shell ProtocolSSH)は、セキュリティで保護されていないネットワーク上でネットワークサービスを安全に運用するための暗号ネットワークプロトコルです [2]その最も注目すべきアプリケーションは、リモートログインコマンドライン実行です。

SSHアプリケーションは、クライアントサーバーアーキテクチャに基づいており、 SSHクライアントインスタンスをSSHサーバーに接続します。[3] SSHは、3つの主要な階層コンポーネントで構成される階層型プロトコルスイートとして動作します。トランスポート層は、サーバー認証、機密性、および整合性を提供します。ユーザー認証プロトコル、サーバーに対してユーザーを検証します。接続プロトコル、暗号化されたトンネルを複数の論理通信チャネルに多重化します。[2]

SSHは、Unixライクなオペレーティングシステム上で、 Telnetの代わりとして、およびBerkeley Remote Shell(rsh)や関連するrloginおよびrexecプロトコルなどのセキュリティで保護されていないリモートUnixシェルプロトコルの代わりとして設計されました。これらはすべて、認証トークンの安全でないプレーンテキスト送信を使用します。

SSHは、フィンランドのコンピューター科学者TatuYlönenによって1995年に最初に設計されました。その後のプロトコルスイートの開発は、いくつかの開発者グループで進められ、実装のいくつかのバリエーションが作成されました。プロトコル仕様は、SSH-1とSSH-2と呼ばれる2つの主要なバージョンを区別します。最も一般的に実装されているソフトウェアトラックはOpenSSHで、1999年にOpenBSD開発者によってオープンソースソフトウェアとしてリリースされました。実装は、組み込みシステムを含む、一般的に使用されているすべてのタイプのオペレーティングシステムに配布されます。

定義

SSHは、公開鍵暗号を使用してリモートコンピューターを認証し、必要に応じてユーザーの認証を許可します。[3]

SSHはいくつかの方法で使用できます。最も簡単な方法では、通信チャネルの両端で、自動生成された公開鍵と秘密鍵のペアを使用してネットワーク接続を暗号化し、パスワードを使用してユーザーを認証します。

公開鍵と秘密鍵のペアがユーザーによって手動で生成される場合、認証は基本的に鍵ペアの作成時に実行され、パスワードプロンプトなしでセッションが自動的に開かれる場合があります。このシナリオでは、公開鍵は、一致する秘密鍵の所有者へのアクセスを許可する必要があるすべてのコンピューターに配置され、所有者は秘密を保持します。認証は秘密鍵に基づいていますが、認証中に鍵がネットワークを介して転送されることはありません。SSHは、公開鍵を提供している同じ人物が一致する秘密鍵も所有していることを確認するだけです。

SSHのすべてのバージョンで、不明な公開鍵を検証すること、つまり、公開鍵をIDに関連付けることは、それらを有効として受け入れる前に重要です。検証せずに攻撃者の公開鍵を受け入れると、許可されていない攻撃者が有効なユーザーとして承認されます。

認証:OpenSSHキー管理

Unixライクなシステムでは、許可された公開鍵のリストは通常​​、リモートログインを許可されているユーザーのホームディレクトリのファイル〜/ .ssh / authorized_keysに保存されます[4]このファイルは、所有者とルート以外の人が書き込みできない場合にのみSSHによって尊重されます。公開鍵がリモートエンドに存在し、一致する秘密キーがローカルエンドに存在する場合、パスワードの入力は不要になります。ただし、セキュリティを強化するために、秘密鍵自体をパスフレーズでロックすることができます。

秘密鍵は標準の場所でも検索でき、そのフルパスはコマンドライン設定(sshの場合はオプション-i )として指定できます。ssh-keygenユーティリティは、公開鍵と秘密鍵を常にペアで生成します。

SSHは、自動生成されたキーによって暗号化されるパスワードベースの認証もサポートしています。この場合、攻撃者は正当なサーバー側を模倣し、パスワードを要求して取得する可能性があります(man-in-the-middle攻撃)。ただし、SSHはサーバー側が以前に使用したキーを記憶しているため、これは2つの側が以前に認証されたことがない場合にのみ可能です。SSHクライアントは、以前は不明だった新しいサーバーのキーを受け入れる前に警告を発します。サーバー側からパスワード認証を無効にすることができます。

使用法

SSHは通常、リモートマシンにログインしてコマンドを実行するために使用されますが、トンネリングTCPポートの転送 、およびX11接続もサポートします。関連するSSHファイル転送(SFTP)またはセキュアコピー(SCP)プロトコルを使用してファイルを転送できます。[3] SSHはクライアントサーバーモデルを使用します。

SSHクライアントプログラムは通常、リモート接続を受け入れるSSHデーモンへの接続を確立するために使用されます。どちらも、macOS 、 LinuxのほとんどのディストリビューションOpenBSDFreeBSDNetBSDSolarisOpenVMSなど、ほとんどの最新のオペレーティングシステムに一般的に存在します。特に、Windows 10バージョン1709より前のバージョンのWindowsには、デフォルトでSSHが含まれていません。プロプライエタリフリーウェアオープンソース(例:PuTTY[5]また、Cygwinの一部であるOpenSSHのバージョン[6])さまざまなレベルの複雑さと完全性のバージョンが存在します。UNIXライクなシステム(Konquerorなど)のファイルマネージャーは、FISHプロトコルを使用して、ドラッグアンドドロップで分割ペインのGUIを提供できます。オープンソースのWindowsプログラムWinSCP [7]は、バックエンドとしてPuTTYを使用して、同様のファイル管理(同期、コピー、リモート削除)機能を提供します。WinSCP [8]とPuTTY [9]はどちらも、クライアントマシンにインストールしなくても、USBドライブから直接実行できるようにパッケージ化されて利用できます。WindowsでSSHサーバーを設定するには、通常、設定アプリで機能を有効にする必要があります。Windows 10バージョン1709、OpenSSHの公式Win32ポートが利用可能です。

SSHは、接続の問題を解決し、クラウドベースの仮想マシンをインターネット上に直接公開するというセキュリティの問題を回避するために、クラウドコンピューティングで重要です。SSHトンネルは、ファイアウォールを介して仮想マシンへのインターネット経由の安全なパスを提供できます。[10]

IANAは、このプロトコルにTCP ポート22、UDPポート22、およびSCTPポート22を割り当てました。[11] IANAは、SSHサーバーの標準TCPポート22を2001年にはよく知られたポートの1つとしてリストしていました。 [12] SSHは、コネクション型トランスポート層プロトコルとしてTCPではなくSCTPを使用して実行することもできます。[13]

歴史的発展

バージョン1

1995年、フィンランドのヘルシンキ工科大学の研究者であるTatuYlönenは、大学のネットワークでのパスワード盗聴攻撃によって促されたプロトコルの最初のバージョン(現在はSSH-1と呼ばれています)を設計しました。[14] SSHの目標は、強力な認証を提供せず、機密性を保証しなかった以前のrloginTELNETFTP [15]、およびrshプロトコルを置き換えることでした。Ylönenは彼の実装をフリーウェアとしてリリースしました1995年7月、このツールの人気は急速に高まりました。1995年の終わりにかけて、SSHユーザーベースは50か国で20,000ユーザーに増加しました。[要出典]

1995年12月、YlönenはSSHを販売および開発するためにSSH CommunicationsSecurityを設立しました。SSHソフトウェアの元のバージョンは、GNU libgmpなどのさまざまなフリーソフトウェアを使用していましたが、SSH Communications Securityによってリリースされた後のバージョンは、ますます独自のソフトウェアに進化しました

2000年までにユーザー数は200万人に増加したと推定されています。[16]

バージョン2

「Secsh」は、SSHプロトコルのバージョン2を担当するIETFワーキンググループの正式なインターネットエンジニアリングタスクフォース(IETF)の名前でした。[17] 2006年に、プロトコルの改訂版であるSSH-2が標準として採用されました。このバージョンはSSH-1と互換性がありません。SSH-2は、SSH-1よりもセキュリティと機能の両方が向上しています。たとえば、セキュリティの向上は、Diffie-Hellman鍵交換と、メッセージ認証コードによる強力な整合性チェックによって実現されますSSH-2の新機能には、単一のSSH接続を介して任意の数のシェルセッションを実行する機能が含まれます。[18]SSH-1に対するSSH-2の優位性と人気により、libssh(v0.8.0 +)、[19] Lsh [20]Dropbear [21]などの一部の実装はSSH-2プロトコルのみをサポートします。

バージョン1.99

2006年1月、バージョン2.1が確立された後、RFC 4253は、2.0および以前のバージョンをサポートするSSHサーバーがそのプロトコルバージョンを1.99として識別する必要があることを指定しました。[22]このバージョン番号は、過去のソフトウェアリビジョンを反映していませんが、下位互換性を識別する方法を反映しています。

OpenSSHとOSSH

1999年、開発者は、無料のソフトウェアバージョンの可用性を望んで、オープンソースライセンスの下で最後にリリースされた元のSSHプログラムの1.2.12リリースからソフトウェア開発を再開しました。これは、BjörnGrönvallのOSSHソフトウェアのコードベースとして機能しました。その後まもなく、OpenBSD開発者はGrönvallのコードをフォークし、 OpenSSHを作成しました。これはOpenBSDのリリース2.6に同梱されていました。このバージョンから、OpenSSHを他のオペレーティングシステムに移植するための「移植性」ブランチが形成されました。[23]

2005年の時点でOpenSSHは単一の最も人気のあるSSH実装であり、多数のオペレーティングシステムディストリビューションのデフォルトバージョンです。一方、OSSHは廃止されました。[24] OpenSSHは引き続き維持され、SSH-2プロトコルをサポートし、OpenSSH7.6リリースのコードベースからSSH-1サポートを削除しました。

を使用します

SSH経由でX11アプリケーションをトンネリングする例:ユーザー「josh」がローカルマシン「foofighter」からリモートマシン「tengwar」に「SSHで接続」してxeyesを実行しました。
Windowsで実行されているPuTTYを使用してSSH経由でOpenWrtにログインします

SSHは、ほとんどのUnixバリアント(LinuxAppleのmacOSを含むBSDSolaris)やMicrosoft Windowsなど、多くのプラットフォームの多くのアプリケーションで使用できるプロトコルです以下の一部のアプリケーションでは、特定のSSHクライアントまたはサーバーでのみ使用可能または互換性のある機能が必要になる場合があります。たとえば、SSHプロトコルを使用してVPNを実装することは可能ですが、現在はOpenSSHサーバーとクライアントの実装でのみ可能です。

  • リモートホスト上のシェルにログインする場合(Telnetrloginを置き換えます)
  • リモートホストで単一のコマンドを実行する場合(rshを置き換える)
  • リモートサーバーへの自動(パスワードなし)ログインを設定する場合(たとえば、OpenSSH [25]を使用)
  • rsyncと組み合わせて、ファイルを効率的かつ安全にバックアップ、コピー、ミラーリングします
  • ポート転送
  • トンネリング用(異なるネットワーク間でパケットルーティングする、または2つのブロードキャストドメインを1つにブリッジするVPNと混同しないでください)。
  • 本格的な暗号化VPNとして使用します。OpenSSHサーバーとクライアントのみがこの機能をサポートしていることに注意してください。
  • リモートホストからXを転送する場合(複数の中間ホストを介して可能)
  • SOCKSプロトコルをサポートするSSHクライアントとの暗号化されたプロキシ接続を介してWebを閲覧するため
  • SSHFSを使用して、リモートサーバー上のディレクトリをローカルコンピュータ上のファイルシステムとして安全にマウントするため。
  • 上記のメカニズムの1つまたは複数を介したサーバーの自動リモート監視および管理用。
  • SSHをサポートするモバイルまたは組み込みデバイスでの開発用。
  • ファイル転送プロトコルを保護するため。

ファイル転送プロトコル

Secure Shellプロトコルは、いくつかのファイル転送メカニズムで使用されます。

アーキテクチャ

SSH-2バイナリパケットの図。

SSHプロトコルには、次の3つのコンポーネントを分離した階層化アーキテクチャがあります。

  • トランスポート層(RFC 4253)は通常、 TCP / IP伝送制御プロトコル(TCP)を使用し、サーバーのリスニングポートとしてポート番号22を予約します。この層は、初期の鍵交換とサーバー認証を処理し、暗号化、圧縮、および整合性の検証をセットアップします。それぞれ最大32,768バイトのサイズのプレーンテキストパケットを送受信するためのインターフェイスを上位層に公開しますが、実装ごとにそれ以上のサイズを許可できます。トランスポート層は、通常1 GBのデータが転送された後、または1時間経過した後のいずれか早い方で、キーの再交換も手配します。
  • ユーザー認証レイヤー(RFC 4252)は、クライアント認証を処理し、一連の認証アルゴリズムを提供します認証はクライアント主導です。パスワードの入力を求められた場合、サーバーではなくSSHクライアントのプロンプトである可能性があります。サーバーは、クライアントの認証要求に応答するだけです。広く使用されているユーザー認証方法には、次のものがあります。
    • password:パスワードを変更できる機能を含む、簡単なパスワード認証の方法。すべてのプログラムがこのメソッドを実装しているわけではありません。
    • publickey:公開鍵ベースの認証の方法。通常は少なくともDSAECDSA、またはRSAキーペアをサポートし、他の実装もX.509証明書をサポートします。
    • キーボードインタラクティブ(RFC 4256):サーバーが情報を入力するための1つ以上のプロンプトを送信し、クライアントがそれらを表示して、ユーザーが入力した応答を送り返す、用途の広い方法。S / KeySecurIDなどのワンタイムパスワード認証を提供するために使用されますPAMがパスワード認証を効果的に提供するための基盤となるホスト認証プロバイダーである場合に一部のOpenSSH構成で使用され、プレーンなパスワード認証方法のみをサポートするクライアントでログインできない場合があります。
    • Kerberos 5NTLMなどの外部メカニズムを使用してSSH認証を実行するための拡張可能なスキームを提供し、SSHセッションにシングルサインオン機能を提供するGSSAPI認証方式これらのメソッドは通常、組織で使用するための商用SSH実装によって実装されますが、OpenSSHには動作するGSSAPI実装があります。
  • 接続層(RFC 4254)は、提供されるSSHサービスを定義するチャネル、チャネル要求、およびグローバル要求の概念を定義します単一のSSH接続を複数の論理チャネルに同時に多重化して、それぞれがデータを双方向に転送することができます。チャネル要求は、端末ウィンドウのサイズの変更やサーバー側プロセスの終了コードなど、帯域外のチャネル固有のデータを中継するために使用されます。さらに、各チャネルは、受信ウィンドウサイズを使用して独自のフロー制御を実行します。SSHクライアントは、グローバルリクエストを使用してサーバー側のポートを転送するようにリクエストします。標準のチャネルタイプは次のとおりです。
    • ターミナルシェル用のシェル、SFTPおよびexecリクエスト(SCP転送を含む)
    • クライアントからサーバーへの転送接続用のdirect-tcpip
    • サーバーからクライアントに転送される接続のforwarded-tcpip
  • SSHFP DNSレコード(RFC 4255)は、ホストの信頼性の検証を支援するために、公開ホストキーのフィンガープリントを提供します。

このオープンアーキテクチャはかなりの柔軟性を提供し、セキュアシェル以外のさまざまな目的でSSHを使用できるようにします。トランスポート層だけの機能は、トランスポート層セキュリティ(TLS)に匹敵します。ユーザー認証レイヤーは、カスタム認証方法を使用して高度に拡張できます。また、接続レイヤーは、多くのセカンダリセッションを単一のSSH接続に多重化する機能を提供します。これは、 BEEPに匹敵する機能であり、TLSでは使用できません。

アルゴリズム

脆弱性

SSH-1

1998年に、このバージョンのプロトコルで使用されるCRC-32からのデータ整合性保護が不十分なため、暗号化されたSSHストリームにコンテンツを不正に挿入できる脆弱性がSSH1.5で説明されました。[31] [32] SSH補償攻撃検出器[33]として知られる修正がほとんどの実装に導入されました。これらの更新された実装の多くには、攻撃者がSSHデーモン(通常はroot)の権限で任意のコードを実行できる 新しい整数オーバーフローの脆弱性[34]が含まれていました。

2001年1月に、攻撃者がIDEAで暗号化されたセッションの最後のブロックを変更できる脆弱性が発見されました。[35]同じ月に、悪意のあるサーバーがクライアント認証を別のサーバーに転送することを可能にする別の脆弱性が発見されました。[36]

SSH-1には脆弱性をもたらす固有の設計上の欠陥があるため、現在では一般的に廃止されていると見なされており、SSH-1へのフォールバックを明示的に無効にすることで回避する必要があります。[36]最新のサーバーとクライアントのほとんどはSSH-2をサポートしています。[37]

CBC平文回復

2008年11月、SSHのすべてのバージョンで理論上の脆弱性が発見され、当時の標準のデフォルト暗号化モードであるCBCを使用して暗号化された暗号文のブロックから最大32ビットの平文を回復できました[38]最も簡単な解決策は、CBCモードの代わりにCTR、カウンターモードを使用することです。これにより、SSHが攻撃に対して耐性を持つようになります。[38]

NSAによる復号化の疑い

2014年12月28日、Der Spiegelは、内部告発者のEdward Snowdenによって漏洩した機密情報[39]を公開しました。これは、国家安全保障局がSSHトラフィックの一部を復号化できる可能性があることを示唆しています。このようなプロセスに関連する技術的な詳細は開示されていません。CIAハッキングツールBothanSpyGyrfalconの2017年の分析では、SSHプロトコルが危険にさらされていないことが示唆されました。[40]

標準ドキュメント

IETF「secsh」ワーキンググループによる以下のRFCの出版物は、提案されたインターネット標準としてSSH-2を文書化しています。

  • RFC  4250Secure Shell(SSH)プロトコルで割り当てられた番号
  • RFC  4251セキュアシェル(SSH)プロトコルアーキテクチャ
  • RFC  4252セキュアシェル(SSH)認証プロトコル
  • RFC  4253セキュアシェル(SSH)トランスポート層プロトコル
  • RFC  4254セキュアシェル(SSH)接続プロトコル
  • RFC  4255DNSを使用してセキュアシェル(SSH)キーフィンガープリントを安全に公開する
  • RFC  4256Secure Shell Protocol(SSH)の汎用メッセージ交換認証
  • RFC  4335Secure Shell(SSH)セッションチャネルブレーク拡張
  • RFC  4344セキュアシェル(SSH)トランスポート層暗号化モード
  • RFC  4345Secure Shell(SSH)トランスポート層プロトコルのArcfourモードの改善

プロトコル仕様は、後で次の出版物によって更新されました。

  • RFC  4419セキュアシェル(SSH)トランスポート層プロトコルのDiffie-Hellmanグループ交換(2006年3月)
  • RFC  4432セキュアシェル(SSH)トランスポート層プロトコルのRSAキー交換(2006年3月)
  • RFC  4462汎用セキュリティサービスアプリケーションプログラムインターフェイス(GSS-API)認証およびセキュアシェル(SSH)プロトコルのキー交換(2006年5月)
  • RFC  4716セキュアシェル(SSH)公開鍵ファイル形式(2006年11月)
  • RFC  4819Secure Shell公開鍵サブシステム(2007年3月)
  • RFC  5647Secure Shellトランスポート層プロトコルのAESガロアカウンターモード(2009年8月)
  • RFC  5656Secure Shellトランスポート層での楕円曲線アルゴリズムの統合(2009年12月)
  • RFC  6187Secure Shell認証用のX.509v3証明書(2011年3月)
  • RFC  6239Secure Shell(SSH)用のスイートB暗号化スイート(2011年5月)
  • RFC  6594SSHFPリソースレコードでのRSA、デジタル署名アルゴリズム(DSA)、および楕円曲線DSA(ECDSA)でのSHA-256アルゴリズムの使用(2012年4月)
  • RFC  6668Secure Shell(SSH)トランスポート層プロトコルのSHA-2データ整合性検証(2012年7月)
  • RFC  7479Ed25519 SSHFPリソースレコード(2015年3月)
  • RFC  5592簡易ネットワーク管理プロトコル(SNMP)のセキュアシェルトランスポートモデル(2009年6月)
  • RFC  6242セキュアシェル(SSH)を介したNETCONFプロトコルの使用(2011年6月)
  • draft-gerhards-syslog-transport-ssh-00 – SYSLOGのSSHトランスポートマッピング(2006年7月)
  • draft-ietf-secsh-filexfer-13 – SSHファイル転送プロトコル(2006年7月)

さらに、OpenSSHプロジェクトには、いくつかのベンダープロトコル仕様/拡張機能が含まれています。

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ a bT 。イルネン; C.ロンビック(2006年1月)。セキュアシェル(SSH)プロトコルアーキテクチャIETFトラスト。土井10.17487 / RFC4251RFC4251_
  3. ^ a b c {{cite ietf | rfc = 4252 | author1 = T。Ylonen | author2 = C。Lonvick | date = 2006年1月| title =セキュアシェル(SSH)認証プロトコル|パブリッシャー= IETFトラスト
  4. ^ 「許可されたキーを設定する方法」2011年5月10日にオリジナルからアーカイブされました。
  5. ^ 「PuTTYをダウンロード-Windows用の無料のSSHおよびtelnetクライアント」Putty.org。2014-05-27にオリジナルからアーカイブされました2014年4月28日取得
  6. ^ 「Cygwinパッケージリスト」2016年1月5日取得
  7. ^ 「WinSCPホームページ」2014-02-17にオリジナルからアーカイブされました。
  8. ^ 「PortableApps.comのWinSCPページ」2014-02-16にオリジナルからアーカイブされました。
  9. ^ 「PortableApps.comのPuTTYページ」2014-02-16にオリジナルからアーカイブされました。
  10. ^ Amies、A; ウー、CF; 王、GC; Criveti、M(2012)。「クラウド上のネットワーキング」IBMdeveloperWorks2013年6月14日にオリジナルからアーカイブされました。
  11. ^ 「サービス名およびトランスポートプロトコルポート番号レジストリ」
  12. ^ 「サービス名およびトランスポートプロトコルポート番号レジストリ」iana.org2001年6月4日にオリジナルからアーカイブされました。
  13. ^ Seggelmann、R。; Tuxen、M。; Rathgeb、EP(2012年7月18〜20日)。「SSHoverSCTP —マルチチャネルプロトコルをSCTPに適合させることにより最適化する」。通信システム、ネットワークおよびデジタル信号処理(CSNDSP)、2012年第8回国際シンポジウム:1–6。土井10.1109 /CSNDSP.2012.6292659ISBN 978-1-4577-1473-3S2CID8415240 _
  14. ^ タトュ・ウルネン。「新しいスケルトンキー:ネットワーク環境のロックを変更する」2017年8月20日にオリジナルからアーカイブされました。
  15. ^ タトュ・ウルネン。「SSHポート」2017年8月3日にオリジナルからアーカイブされました。
  16. ^ ニコラスロサスコとデビッドラロシェル。「レガシー市場でより安全なテクノロジーが成功する方法と理由:SSHの成功からの教訓」(PDF)Barrett and Silverman、SSH、Secure Shell:The Definitive Guide、O'Reilly&Associates(2001)を引用しています。大学コンピュータサイエンス学科 バージニア州。2006年6月25日のオリジナルからアーカイブ(PDF)2006年5月19日取得
  17. ^ 「Secshプロトコルドキュメント」VanDyke Software、Inc2010年1月13日にオリジナルからアーカイブされました。
  18. ^ 「SSHのよくある質問」2004-10-10にオリジナルからアーカイブされました。
  19. ^ 「libssh」
  20. ^ 「SecureShellプロトコルのGNU実装」2012-02-04にオリジナルからアーカイブされました。
  21. ^ 「DropbearSSH」2011年10月14日にオリジナルからアーカイブされました。
  22. ^ 「RFC4253」セクション5.古いSSHバージョンとの互換性。2010年7月4日にオリジナルからアーカイブされました。、IETF
  23. ^ 「OpenSSH:プロジェクトの歴史とクレジット」openssh.com。2004-12-22。2013年12月24日にオリジナルからアーカイブされました2014年4月27日取得
  24. ^ 「VU#419241のOSSH情報」CERTコーディネーションセンター2006-02-15。2007年9月27日にオリジナルからアーカイブされました。いずれにせよ、osshは古くて時代遅れであり、その使用はお勧めしません。
  25. ^ Sobell、Mark(2012)。Linuxコマンド、エディター、およびシェルプログラミングの実用ガイド(第3版)。ニュージャージー州アッパーサドルリバー:プレンティスホール。pp。702–704。ISBN 978-0133085044
  26. ^ RFC 8709
  27. ^ a b Stebila、D。; Green J.(2009年12月)。「RFC5656-セキュアシェルトランスポート層での楕円曲線アルゴリズムの統合」2012年7月19日にオリジナルからアーカイブされました2012年11月12日取得 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  28. ^ ミラー、D。; Valchev、P。(2007年9月3日)。「SSHトランスポート層プロトコル/draft-miller-secsh-umac-00.txtでのUMACの使用」2014年8月19日にオリジナルからアーカイブされました2012年11月12日取得 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  29. ^ RFC 4253
  30. ^ RFC 5647
  31. ^ 「SSH挿入攻撃」コアセキュリティテクノロジー2011年7月8日にオリジナルからアーカイブされました。
  32. ^ 「脆弱性に関する注意VU#13877-弱いCRCにより、ブロック暗号で暗号化されたSSHセッションへのパケットインジェクションが可能になります」USCERT2010年7月10日にオリジナルからアーカイブされました。
  33. ^ 「SSHCRC-32補償攻撃検出器の脆弱性」SecurityFocus2008年7月25日にオリジナルからアーカイブされました。
  34. ^ 「脆弱性に関する注意VU#945216-SSHCRC32攻撃検出コードにリモート整数オーバーフローが含まれています」USCERT2005-10-13にオリジナルからアーカイブされました。
  35. ^ 「脆弱性に関する注意VU#315308-CRCが弱いと、IDEAで暗号化されたSSHパケットの最後のブロックが予告なしに変更される可能性があります」USCERT2010年7月11日にオリジナルからアーカイブされました。
  36. ^ a b 「脆弱性に関する注意事項VU#684820-SSH-1を使用すると、悪意のあるサーバーから別のサーバーにクライアント認証を転送できます」USCERT2009年9月1日にオリジナルからアーカイブされました。
  37. ^ 「認証にSSHキーを使用する方法」アップクラウド2019年11月29日取得
  38. ^ a b 「脆弱性ノートVU#958563-SSHCBCの脆弱性」USCERT2011年6月22日にオリジナルからアーカイブされました。
  39. ^ 「詮索好きな目:インターネットセキュリティに関するNSAの戦争の内部」シュピーゲルオンライン2014年12月28日。2015年1月24日のオリジナルからアーカイブ。
  40. ^ Ylonen、Tatu(2017年8月3日)。「BothanSpy&Gyrfalcon-SSH用のCIAハッキングツールの分析」ssh.com 2018年7月15日取得

さらに読む

外部リンク