Fedora 11 をデスクトップシステムにインストールしましたが、 sshd を機能させたいと考えています。これらは私が行ったステップです:
system-config-firewall
を使用して、信頼できるサービスとしてsshdを有効にしましたservice restart sshd
を使用して、sshdをサービスとして再起動しましたLocalhostへのSSH接続は可能ですが、リモートマシンからのSSH接続はまだ使用できません。不足しているものはありますか?
1ホストへのファイアウォールを無効にする(ファイアウォールではないことを確認するのに十分な長さのみ)
2ターミナルを開き、su
をrootユーザーにして、/etc/init.d/sshd start
これにより、少なくとも、発生する可能性のあるエラーはすべて表示されます。うまくいけば、それは開始を認めます
3 ファイアウォールを有効にするリモートホストから接続して、ファイアウォールに問題がないことを確認します
これからのエラーは、あなたが投稿した場合、私たちはすべて助けることができるかもしれません。
ステップ2で、コンピュータがキーを生成していることに気づくかもしれません。これは、それが以前に機能しなかった理由を説明します。それがキーを作成しなかった場合、それはそれらが以前に生成され、あなたがO.Kであることを意味します。
私は愚かな間違いをしていた。
問題は、間違ったIPアドレスにアクセスしようとしたことでした。マシンが再起動すると、DHCPによってIPアドレスが変更され、古いIPアドレスにアクセスしようとし続けました。
これが、ローカルSSH接続が機能していたがリモートでは機能しなかった理由です。 IPアドレスを確認するには、以前にifconfig
を実行する必要がありました。
これには2つのステップしかありません。
system-config-firewall
を使用して、sshdを信頼できるサービスとして有効にしますservice sshd start
を使用して、sshdをサービスとして開始します2番目のステップでは、キーが生成されていることを確認します。 SELinux に触れる必要はまったくありません。
SELinuxはnotここに問題があります。 SELinuxを無効にしたり、permissiveモードに設定したりしないでください。そうする理由は全くありません。私のラップトップは4月の初めからSELinuxを強制モードで問題なくF11で実行しています。
SELinuxは、手動でキーを作成して/ etc/sshなどに配置した場合にのみ問題になりますが、それは問題ではないため、SELinuxはそのままにしておきます。
Fedoraには、たとえばArchのような非常に奇妙なhosts.denyルールはありません。また、デフォルトではiptablesのsshをブロックしません。
/ var/log/secureと/ var/log/messagesの出力を、sshdを起動しようとしている頃に投稿してください。私がお手伝いできるかどうか確認します。
このコマンドを使用してEnnable SSHD systemctl enable sshd.service
su -
systemctl enable sshd.service
systemctl start sshd.service
構成され、実行されていることを確認するには:
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がリモートでログインすることを許可することはあまりお勧めできません。
いくつかのデバッグ方法:
Sshdが実際に実行されていることを確認しましたか。例えばps aux|grep sshd
およびnetstat -nltp|grep 22
(rootとして)
sshd
が実行されていると想定して、ネットワークトラフィックと、サーバーのsshd
プロセスとクライアントssh
プロセスで何が起こっているかを確認します。
LoclhostからホストにSSH接続できますか?
/ etc/ssh/sshd_configのsshロギングを表示して、ログを確認します。
サーバーホスト上のtcpdump -i any tcp dst port 22 and src Host <ssh_client_ip/Host>
クライアントホスト上のtcpdump -i any tcp dst port 22 and dst Host <ssh_server_ip/Host>
サーバー上のsshd
のリスニングインスタンスにstrace -F -p <listening sshd process pid>
をアタッチして、何が起こっているかを確認します。
サーバーに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
。
/ 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がローカルマシンからは機能しているが外部マシンからは機能していない場合があります。
おそらく selinux が実行されています。最近のFedoraのインストールでは、かなり制限された一連のポリシーにより、デフォルトでこれが有効になっています。