web-dev-qa-db-ja.com

Linux（Fedora10およびCentOS5.2）でSSHホストキーを許可する方法

Mac OS X 10.5 LeopardServerベースの中央バックアップサーバーからFedora10とCentOS5.2を実行している2つのLinuxサーバーにSSHホストキーを設定しようとしています。私たちが通常行うプロセスは機能し、鍵を〜/ .ssh/authorized_keysに入れますが、それでもパスワードの入力を求められます。

私はこれらのボックスの通常の管理者ではありませんが、デフォルトではおそらくSSHホストキーが無効になっていることを理解しています。 SSHホストキーを有効にするにはどうすればよいですか？

更新：/etc/ssh/ssd_configで「PubkeyAuthenticationyes」のコメントを解除してservice restart sshdを実行しましたが、機能しませんでした。 3行すべて（「RSAAuthentication」、「PubkeyAuthentication」、および「AuthorizedKeysFile」）のコメントを外して、〜/ .sshの権限を修正し、再試行しました。まだ愛はない。

ssh -v user@Hostを実行すると、パスワードの入力を求める前とGSSエラーの後に次のように表示されます。

debug1: Next authentication method: publickey
debug1: Trying private key: /Users/shortname/.ssh/identity
debug1: Trying private key: /Users/shortname/.ssh/id_rsa
debug1: Trying private key: /Users/shortname/.ssh/id_dsa
debug1: Next authentication method: password

さらなる提案？

別の更新：~/および~/.ssh/の権限は700です。

ホストキーを作成するために実行したコマンドは次のとおりです。

cat /blah/ssh_keys_for_shortname/id_dsa.pub | ssh -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa Host.domain.tld 'cat - >> ~/.ssh/authorized_keys'

そして、私が接続しようとするとき、私は使います：

ssh --verbose -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa Host.domain.tld

したがって、明らかにDSAキーを使用しています。 ~/.ssh/authorized_keys2の名前を変更しようとしましたが、役に立ちません。

/blah/ssh_keys_for_shortname/ではなく、デフォルトの場所にキーを保存したいのですが、自分では制御できません。

/var/log/audit/audit.logを見て接続しようとすると、次のようになります。

type=CRED_DISP msg=audit(1249426114.642:128): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:setcred acct="shortname" exe="/usr/sbin/sshd" (hostname=Host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_END msg=audit(1249426114.647:129): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:session_close acct="shortname" exe="/usr/sbin/sshd" (hostname=Host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1249426129.524:130): user pid=10633 uid=0 auid=4294967295 ses=4294967295 msg='acct="shortname": exe="/usr/sbin/sshd" (hostname=?, addr=192.168.1.149, terminal=sshd res=failed)'

提案？

linuxsshcentosfedorahostkey
4
morgant

基本は正しいようです。

これが失敗する最も一般的な理由は、リモートauthorized_keysファイルとその上のディレクトリに対する権限です。キーベースの認証を許可する前に、sshdは権限チェックを実行します。結果が気に入らない場合は、認証を許可しません。私は通常、~/.sshを0700に、~/.ssh/authorized_keysを0600に設定します。実際の$ HOMEにはグループ書き込みも書き込み書き込みもできないと思いますが、読み取りは問題ありません。

それでも問題が解決しない場合は、次のステップはサーバー側でデバッグを行うことです。

server$ /usr/sbin/sshd -d -p 2222

次に、クライアントから「デバッグ」サーバーに接続します。

client$ ssh -v user@Host  -p 2222

サーバーのstderrで大量のデバッグ情報を取得します。そこから追跡できなかった認証の問題はまだ発生していません。

10
Insyte

これが私が従うプロセスです。

  1. OS Xサーバーで公開鍵と秘密鍵のペアを作成します。プロンプトが表示されたらパスフレーズを指定しません。

    $ ssh-keygen -b 4096 -C "myusername @ myhostname" -t rsa

  2. OS Xサーバー上の〜/ .ssh/id_rsa.pubの内容を、CentOS/Fedoraホスト上の正しいユーザーのホームディレクトリ内の〜/ ssh/authorized_keysにコピーします。

  3. すべてのホストで権限が正しいことを確認します。ディレクトリ〜/ .sshはモード0700である必要があり、内部のファイルは0600である必要があります（公開鍵には0644を使用できますが、より制限することは問題ありません）。

鍵ベースの認証がまだ機能していない場合は、以下の値が各CentOS/Fedoraホストのsshd_configファイル（/ etc/ssh/sshd_config）に設定されていることを確認してください。 （これらの値はデフォルトである必要があります。）

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

それでも機能しない場合は、ssh -v user@Hostを試して、接続時に何が起こっているかを確認してください。何が起こっているかについての詳細を表示するには、さらにvを追加します。

[〜＃〜] edit [〜＃〜]：/から問題の.sshディレクトリへの完全なディレクトリツリーのアクセス許可を確認してみてください。そのパス内のいずれかのディレクトリがグループまたはすべてのユーザーが書き込み可能な場合、SSHは攻撃を開始します。これを実行して、パス内のすべてのディレクトリのアクセス許可を出力します。

j="" ; for i in `echo ~baumgart/.ssh | sed 's%/% %g'` ; do ls -ld $j/$i ; j=$j/$i ; done

また、ログファイルでCentOS/Fedoraシステムのsshdからのメッセージを確認してください。これには何が問題なのかについての役立つメッセージが含まれているはずです。/var/log/messagesまたは/var/log/auth.logにある必要があります。見つからない場合は、grep sshd /var/log/*を実行してください。

4
baumgart

すでにユーザー/グループの権限を適切に設定している場合は、SELinuxの問題が発生している可能性があります。これを修正する最も簡単な方法は、restorecon -R /home/user/.ssh/。エラーはログインされます/var/log/audit/audit.logとaudit2why発生した可能性のあるSELinux拒否をシステムに説明させるツール。

2
Ophidian

最初に指摘するのは、_/var/log/audit.log_がロギングSELinuxアクティビティであるということです。

そのログをもう少し振り返ると、次のような別のエントリが表示されると思います。

type=AVC msg=audit(xxxxxxxxx.xxx:xxxx): avc: denied { search } for pid=xxxxx comm="sshd" name="xxxxxx" dev=xxxx ino=xxxxxx scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir

これが意味するのは、sshdプロセスがロードされたselinuxポリシーによって制限されており、許可されたキーファイルが置かれているファイルシステムパスにアクセスできないということです。

Selinuxポリシーがアクティブであることを確認するには、sestatusコマンドを実行すると、次の出力が表示されます。

_SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted
_

これが問題であるかどうかをすばやくテストするために、_setenforce permissive_コマンドを発行して、SELinuxを一時的に許容モードに設定できます。その後、sestatusを再度実行すると、次の出力が表示されます。

_SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted
_

Ssh接続を再試行してください。他のすべての構成が正しい場合は、機能するはずです。

今後は、後のパスへのアクセスを許可するカスタムルールを作成する必要がありますが、これはこのヘルプの範囲を超えています。

この変更を永続的にするには（再起動後も存続させる）、_/etc/selinux/config_ファイルを変更して以下を変更する必要があります。

_SELINUX=enforcing
_

に

_SELINUX=permissive
_
2
Bryan Geraghty

/ etc/ssh/sshd_configの「PubkeyAuthenticationyes」？

1
Dom