web-dev-qa-db-ja.com

Fedora 11でsshdを有効にする方法は？

Fedora 11 をデスクトップシステムにインストールしましたが、 sshd を機能させたいと考えています。これらは私が行ったステップです：

  1. system-config-firewallを使用して、信頼できるサービスとしてsshdを有効にしました
  2. service restart sshdを使用して、sshdをサービスとして再起動しました

LocalhostへのSSH接続は可能ですが、リモートマシンからのSSH接続はまだ使用できません。不足しているものはありますか？

linuxfirewallfedorassh
3
vivekian2

1ホストへのファイアウォールを無効にする（ファイアウォールではないことを確認するのに十分な長さのみ）

2ターミナルを開き、suをrootユーザーにして、/etc/init.d/sshd startこれにより、少なくとも、発生する可能性のあるエラーはすべて表示されます。うまくいけば、それは開始を認めます

3 ファイアウォールを有効にするリモートホストから接続して、ファイアウォールに問題がないことを確認します

これからのエラーは、あなたが投稿した場合、私たちはすべて助けることができるかもしれません。

ステップ2で、コンピュータがキーを生成していることに気づくかもしれません。これは、それが以前に機能しなかった理由を説明します。それがキーを作成しなかった場合、それはそれらが以前に生成され、あなたがO.Kであることを意味します。

5
bobby

私は愚かな間違いをしていた。

問題は、間違ったIPアドレスにアクセスしようとしたことでした。マシンが再起動すると、DHCPによってIPアドレスが変更され、古いIPアドレスにアクセスしようとし続けました。

これが、ローカルSSH接続が機能していたがリモートでは機能しなかった理由です。 IPアドレスを確認するには、以前にifconfigを実行する必要がありました。

これには2つのステップしかありません。

  • system-config-firewallを使用して、sshdを信頼できるサービスとして有効にします
  • service sshd startを使用して、sshdをサービスとして開始します

2番目のステップでは、キーが生成されていることを確認します。 SELinux に触れる必要はまったくありません。

6
vivekian2

SELinuxはnotここに問題があります。 SELinuxを無効にしたり、permissiveモードに設定したりしないでください。そうする理由は全くありません。私のラップトップは4月の初めからSELinuxを強制モードで問題なくF11で実行しています。

SELinuxは、手動でキーを作成して/ etc/sshなどに配置した場合にのみ問題になりますが、それは問題ではないため、SELinuxはそのままにしておきます。

Fedoraには、たとえばArchのような非常に奇妙なhosts.denyルールはありません。また、デフォルトではiptablesのsshをブロックしません。

/ var/log/secureと/ var/log/messagesの出力を、sshdを起動しようとしている頃に投稿してください。私がお手伝いできるかどうか確認します。

3
wzzrd

このコマンドを使用してEnnable SSHD systemctl enable sshd.service

su -
systemctl enable sshd.service
systemctl start sshd.service
3
ebuggi

構成され、実行されていることを確認するには：

chkconfig --list sshd
service sshd status

動作していることがわかったら、起動時に表示されることを確認しました。次に、それを機能させるために、次のルールを/ etc/sysconfig/iptablesに追加しました。

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

それから私はiptablesを再起動しました：

service iptables restart

/etc/selinux/configを編集して次のように設定することで、SELINUXも無効にしました。

SELINUX=disabled

念のため再起動した可能性があります。これらは、リモートSSHログインを取得するために実行される手順です。

注：rootログインを許可しないようにsshd.confを設定しました。 rootユーザーとしてログインする場合は、現在のsshd.confファイルでその設定を再確認してください。セキュリティ上の理由から、rootがリモートでログインすることを許可することはあまりお勧めできません。

0
netlinxman

いくつかのデバッグ方法：

Sshdが実際に実行されていることを確認しましたか。例えばps aux|grep sshdおよびnetstat -nltp|grep 22（rootとして）

sshdが実行されていると想定して、ネットワークトラフィックと、サーバーのsshdプロセスとクライアントsshプロセスで何が起こっているかを確認します。

  1. LoclhostからホストにSSH接続できますか？

  2. / etc/ssh/sshd_configのsshロギングを表示して、ログを確認します。

  3. サーバーホスト上のtcpdump -i any tcp dst port 22 and src Host <ssh_client_ip/Host>

  4. クライアントホスト上のtcpdump -i any tcp dst port 22 and dst Host <ssh_server_ip/Host>

  5. サーバー上のsshdのリスニングインスタンスにstrace -F -p <listening sshd process pid>をアタッチして、何が起こっているかを確認します。

  6. サーバーにsshし、strace、つまりstrace ssh <user>@<Host>からクライアントを実行して、何が起こっているかを確認します

また、サーバーのsshdサービスを停止し、コマンドラインからデバッグモードでsshdデーモンを実行します。例えば。：

service sshd stop;pkill sshd

sshd -d3

または

service sshd stop;pkill sshd

strace sshd -d3。

-d3は、デバッグレベルの高いsshdを実行し、デタッチ/フォークを停止します。つまりそれは実行中の唯一のインスタンスとなり、出力は端末に送られるはずです

また、クライアントのコマンドラインで-oLogLevel=DEBUGを使用して、ノイズを増やすこともできます。

認証にキーを使用している場合は、キーが存在するディレクトリを確認してください。たとえば、~/.sshは十分にプライベートな権限を持っています。例：chown -R ${USERID}. .sshd; chmod -R 700 .sshd。

0
Jason Tan

/ etc内のhosts.denyおよびhosts.allowファイルを確認することもできます。一部のディストリビューションでは、これらはデフォルトで外部ソースからのすべての接続をブロックするように設定されていますが、ローカルマシンからの接続は許可されています。これが、リモートシステムからではなくローカルに接続できる理由です。

Hosts.denyに「ALL：*」または「ALL：PARANOID」行があり、コメント化されていない場合、hosts.allowファイルで明示的に許可されていない外部ソースからの接続はすべて拒否されます。これは一部のディストリビューションではデフォルトの状態で、最初からシステムを改ざんすることからシステムをロックダウンするのに役立ちます。ファイルにコメントのみがある場合、これは問題ではありません。

「ALL：PARANOID」行がhosts.denyにあり、そのままにしておくと、特定のソースからのssh接続を有効にするには、「sshd：」行をhosts.allowファイルに追加する必要があります。特定のIP、FQDN、またはワイルドカードバージョン（つまり、sshd：192.168.0。*または* .mydomain.net）にすることができます。このファイルには通常、「ALL：127.0.0.1」という行があり、ローカルマシンからのあらゆる種類の接続を許可しているため、sshがローカルマシンからは機能しているが外部マシンからは機能していない場合があります。

0
dagorym

おそらく selinux が実行されています。最近のFedoraのインストールでは、かなり制限された一連のポリシーにより、デフォルトでこれが有効になっています。

0
gareth_bowles