Secure Shell

Article on other languages:

• Secure_Shell
• قشرة_آمنة
• SSH
• Secure_Shell
• Secure_Shell
• Secure_Shell
• SSH
• Secure_Shell
• Secure_Shell
• SSH
• Secure_Shell
• Secure_Shell
• SSH
• Secure_shell
• Secure_shell
• Secure_Shell
• Secure_Shell
• Secure_shell
• Secure_Shell
• 시큐어_셸
• SSH
• Secure_Shell
• Secure_Shell
• SSH
• SSH
• SSH
• Secure_shell
• Secure_shell
• SSH
• Secure_Shell
• SSH
• Secure_Shell
• SSH
• SSH

	del.icio.us
	Digg
	Furl
	Reddit
	Rojo
	Add to OnlyWire

Secure Shell（セキュアシェル）は、暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。パスワードなどの認証部分を含むすべてのネットワーク上の通信が暗号化される。スペルアウトするよりも、頭字語のSSH（エスエスエイチ）と呼称することが多い。

そもそもはTelnetやrsh、rloginなどといった、リモートホストのシェルを利用するための既存のプロトコルを代用する手段として考えられていた。TelnetやFTPは、ネットワーク上に平文でパスワードを送信してしまうため、パスワードをネットワーク経路上でのぞき見されてしまう（これを盗聴やスニフと呼ぶ）危険性が高く、商業的なインターネット空間では問題が大きかった。Telnet同様に、リモートホスト間でのファイルコピー用のコマンドrcpを代用するSCPや、FTPを代用するためのSFTPも用意されている。

SSHの暗号通信は、公開鍵暗号（RSA又はDSA）を用いて共通鍵暗号（トリプルDES、AESなど）の共通鍵を暗号化して鍵交換を行い、通信自体は高速な共通鍵暗号を用いる、いわゆるハイブリッド暗号である。また、成りすましを防止するための認証の仕組みも充実している。パスワード認証、公開鍵認証、ワンタイムパスワードなどが提供されており、個々の情報セキュリティポリシーに合わせて選択できる。

現在は、バージョン1とバージョン2の2種類のプロトコルが共存しているが、バージョン1には脆弱性が発見されているためその利用は推奨されない。商用アプリケーションやフリーソフトウェアなど幾つかの実装があり、特許や互換性の問題などでやや混乱があったが、2006年にSSHのプロトコルおよびその関連技術がRFCとして制定された（RFC4250-RFC4256）。ただ、もっとも一般に普及しているのは、オープンソースで開発されているOpenSSHで、Linuxなどでも標準的に利用されているため、現在では単純にSSHと言った場合、OpenSSHの実装系を指していることが多い。

SSHサーバ

• OpenSSH (UNIX)
• SSH Tectia Server (HP-UX, AIX, Windows, Linux, Solaris)
• Reflection for Secure IT (HP-UX, AIX, Windows, Linux, Solaris)

SSHクライアント

• OpenSSH (UNIX)
• PuTTY (Windows, UNIX)
• Tera Term (Windows)
• Poderosa (Windows)
• SSH Tectia Client (HP-UX, AIX, Windows, Linux, Solaris)
• Reflection for Secure IT (HP-UX, AIX, Windows, Linux, Solaris)

SSHのセキュリティリスク

SSHクライアントの利用者がサーバ鍵の指紋を確認しない場合、意図しないリモートコンピュータに接続していても気づかず、通信内容を盗聴される恐れがある。

また、SSHサーバには、設定値が適切でないために発生するセキュリティリスクがある。一例として、OpenSSHにおける以下のような設定があげられる。

• PasswordAuthenticationがdefaultで有効である
• PermitRootLoginがdefaultで有効である
• Protocolがdefaultでssh1を許可している
• Portがdefaultで22で既知である
• ChallengeResponseAuthenticationがdefaultで有効である
• AllowUsersにおいてdefaultですべてのユーザーに許可されている
• 認証にたびたび失敗するhostからの接続を制限しない
• 認証に失敗しても再認証を受け入れるまでウエイト時間を設けない
• defaultではないがX11 port forwardingが有効にできる
• 認証が通るとshellへのアクセスが認められる

これらの状態では、たとえばブルートフォースアタックでセキュリティを突破する事が可能である。実際にセキュリティを破られたサーバが存在し、IPAではこの問題について危険性がある事を勧告している。

OpenSSHを採用しているサーバOSの中には、上記の値をデフォルト値としていないものもある。しかし、デフォルトのsshd_configに対してなんら対策を施していない場合、非常に多くの情報が既知である。攻撃者はパスワードを見つける事だけに専念する事でセキュリティを破り、またroot特権を獲得する事ができる。

この問題に対してのソリューションは、SSHサーバの設定のデフォルト値には危険なものがあることを認識し、対策する事である。

• PasswordAuthentication noにする
• PermitRootLogin noにする。
• Protocol 2にする。
• Portは22以外にする。
• ChallengeResponseAuthentication noにする。
• AllowUsersにおいて特定のユーザーのみ接続を許可する。
• authlogなどで認証失敗を検出したら、そのhostからの接続を遮断する。
• X11 port forwardingは無効にする。
• shellが必要無いのであればpasswdファイルからシェルを取り除く

関連記事

• SSL
• Telnet
• File Transfer Protocol
• SFTP
• Secure copy
• sshfs
• FISH