SSHログインで遅延が発生しています。具体的には、瞬間的な遅延から数秒の遅延までの範囲が見られる箇所が2箇所あります
- sshコマンドを発行して、ログインプロンプトを取得するとの間に
- パスフレーズを入力してからシェルに負荷をかけるまでの間に
今、具体的には、ここでは ssh の詳細のみを見ています。明らかにネットワークの遅延、関係するハードウェアや OS の速度、複雑なログインスクリプトなどが遅延の原因になることがあります。文脈のために、私は膨大な数のlinuxディストリビューションといくつかのSolarisホストにsshしています。ほとんどの場合、ssh サーバの設定は OS のデフォルト設定から変更されていません
どのような ssh サーバの設定に興味がありますか?チューニングできるOS/カーネルのパラメータはありますか？ログインシェルのトリック?などなど?
110 Peter Lyons 2010-07-22
UseDNSを/etc/sshd_configや/etc/ssh/sshd_configでnoに設定してみてください
139 Paul R 2010-07-22
似たような性能の遅いサーバーでssh -vvvを実行したところ、ここでハングアップしてしまいました
debug1: Next authentication method: gssapi-with-mic
/etc/ssh/ssh_configを編集し、その認証方法をコメントアウトすることで、ログインパフォーマンスが正常に戻りました。サーバ上の /etc/ssh/ssh_config にあるものは以下の通りです
GSSAPIAuthentication no
これをサーバー上でグローバルに設定すれば、GSSAPIでの認証を受け付けないようになります。サーバ上でGSSAPIAuthentication noを/etc/ssh/sshd_configに追加してサービスを再起動するだけです
44 Joshua 2010-09-22
私の場合、原因はIPv6の解決で、タイミングアウトしていました。(ホストプロバイダのDNS設定が悪かったのでしょう。) どのステップがハングアップしているかを示すssh -vを実行することで発見しました
解決策としては、sshに-4のオプションをつけることです
ssh -4 me@myserver.com
22 Anthony 2015-08-14
systemdでは、アップグレード後にlogindとのdbus通信でログインがハングアップすることがあるので、logindを再起動する必要があります
systemctl restart systemd-logind
debian 8, arch linx, そして suse のリストにもありました
16 Bastien Durel 2015-05-21
sshを-vオプションでいつでも開始できますが、これは現在何をしているかを表示します
$ ssh -v you@host
あなたが与えた情報では、私はいくつかのクライアント側の設定を提案することしかできません
パスワードを手動で入力していると書いているので、できれば公開鍵認証を使うことをお勧めします。そうすることで、スピードのボトルネックになっているあなたを排除することができます
また、
-xで X 転送を無効にしたり、-aで認証転送を無効にしたりすることもできます (これらはすでにデフォルトで無効になっているかもしれません)。特に、X-forwarding を無効にすることで、クライアントがsshコマンドのために X-server を起動する必要がある場合 (例: OS X の場合) の速度を大幅に向上させることができます
他のすべてのものは、本当にあなたがいつ、どこで、どのような種類の遅延を経験するかに依存しています
9 Benjamin Bannier 2010-07-22
2.については、サーバを変更する必要がなく、root/管理者権限を必要としない回答があります
ユーザ ssh_config” ファイルを編集する必要があります
vi $HOME/.ssh/config
(注意: 存在しない場合は $HOME/.ssh ディレクトリを作成する必要があります)
And add:
Host *
GSSAPIAuthentication no
GSSAPIDelegateCredentials yes
必要であればホストごとに行うことができます
Host linux-srv
HostName 192.158.1.1
GSSAPIAuthentication no
GSSAPIDelegateCredentials yes
IP アドレスがサーバの IP アドレスと一致していることを確認してください。クールな利点の一つは、ssh がこのサーバのオートコンプリートを提供するようになったことです。つまり、ssh lin + Tab と入力すると ssh linux-srv とオートコンプリートされます
7 Huygens 2012-06-29
このファイルに記載されているDNSサーバが正常に動作することを確認するために、サーバ上の/etc/resolv.confを確認し、動作しないDNSは削除してください
時々、とても参考になります
4 Elena Timoshkina 2017-06-08
すでに述べた DNS の問題に加えて、多くの NFS マウントがあるサーバに ssh している場合、quota コマンドが noquota でマウントされていないすべてのファイルシステムの使用量/クォータをチェックするため、パスワードとプロンプトの間に遅延が発生する可能性があります。 Solaris システムでは、デフォルトの /etc/profile でこれを確認し、touch $HOME/.hushlogin を実行することでこれをスキップすることができます
2 alanc 2010-07-22
systemd-logind.serviceを再起動すると数時間だけ問題が解決することがわかりました。sshd_config で UsePAM を yes から no に変更すると、motd は表示されなくなりましたが、高速なログインが可能になりました。セキュリティの問題についてのコメント
2 Chris Blake 2016-07-13
Work fine.
# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh
UseDNSはOpenIndianaでは動作しません!
すべてのオプションについては、「man sshd_config」を読んでください
サーバが解決できない場合は、”LookupClientHostnames no “となります
1 Hugues 2012-04-25
上記の回答のどれも動作せず、DNS逆引き問題に直面している場合は、nscd (ネームサービスキャッシュデーモン)がインストールされて実行されているかどうかを確認することもできます
もしこれが問題だとしたら、DNSキャッシュがなく、ホストファイルにないホスト名を問い合わせるたびに、キャッシュを探す代わりにネームサーバに質問を送っていることが原因です
上記のオプションをすべて試してみましたが、変更が効いたのはnscdを起動することだけでした
また、/etc/nsswitch.confでDNSクエリの解決を行う順番を確認して、hostsファイルを先に使用するようにしましょう
1 altmas5 2013-05-02
これはおそらく Debian/Ubuntu OpenSSH にのみ特有のもので、Debian パッケージメンテナの一人が書いた user-group-modes.patch が含まれています。このパッチは ~/.ssh ファイルに書き込み可能なグループビット (g+w) を設定できるようにします。パッチの secure_permissions() 関数はこのチェックを行います。このチェックのフェーズの一つは、getpwent() を使って各 passwd エントリを調べ、そのエントリの gid とファイルの gid を比較することです
nscd は getpwent() コールをキャッシュしないので、サーバがローカルでない場合、すべての passwd エントリがネットワーク経由で読み込まれてしまいます。私がこれを発見したシステムでは、ssh の呼び出しやシステムへのログインのたびに約 4 秒が追加されていました
修正方法は、chmod g-w ~/.ssh/*を実行して ~/.ssh のすべてのファイルの書き込み可能ビットを削除することです
1 jamesy 2015-10-13
DNS解決がsshログインを遅くする可能性があることを示すすべての回答を完了するには、ファイアウォールのルールが欠落していることがあります。例えば、デフォルトですべての INPUT パケットを DROP した場合
iptables -t filter -P INPUT DROP
の場合は、ssh のポートと DNS リクエストの INPUT を受け付ける必要があります
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
1 RGuillome 2016-12-06
ssh -vvv の接続は、少なくとも20秒間は端末を取得しようとするシステム上でハングアップするまでは、本当にうまくいっていました
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting
サーバー上でsystemctl restart systemd-logindをしたら、またすぐに接続できました
これは debian8 でした!つまり、ここでは systemd が問題だったのですね!
注: Bastien Durelはこの問題についてすでに回答を与えていますが、デバッグ情報が不足しています。これが誰かの役に立つことを願っています
1 mahatmanich 2017-03-04
最近、sshのログインが遅い原因をもう一つ見つけました
/etc/sshd_config に UseDNS no があったとしても、/etc/hosts.deny に /etc/hosts.deny のようなエントリがあれば、sshd は DNS の逆引きを実行するかもしれません
nnn-nnn-nnn-nnn.rev.some.domain.com
DenyHosts がシステムにインストールされている場合に発生する可能性があります
DenyHostsが/etc/hosts.denyにこの手のエントリを入れないようにする方法を誰か知っていると助かります
DenyHosts FAQ, /etc/hosts.deny からエントリを削除する方法についてのリンクです – How can I remove an IP address that DenyHosts blocked?を参照してください
1 Marcelo Roberto Jimenez 2016-10-24
好ましい名前解決方法は、ホストファイルとDNSではないことがわかります
例えば、これは通常の設定になります
[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts: db files nisplus nis dns
hosts: files dns myhostname
最初にhostsファイル（オプション：ファイル）に到達し、次にDNS（オプション：DNS）に到達しますが、別の名前解決システムが追加されていることがわかりますが、それは運用されておらず、逆解決を行おうとする際の遅さの原因となっています
名前解決の順番が正しくない場合は、以下で変更することができます。/etc/nsswitch.conf
http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html から抜粋しました
1 Hans Gruber 2017-07-09
私はすべての答えを試してみましたが、それらのどれもが働いていませんでした
最初にsudo tail -f /var/log/auth.logを実行してsshのログを見てから、別のセッションでssh 172.16.111.166を実行してみたところ、待機中であることに気づきました
/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166
検索した結果、/etc/ssd/ssh_configにこの行を見つけました
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
コメントしたら遅延が無くなりました
1 HamedH 2017-07-22
注：これは “デバッグする方法”、チュートリアルとして始まりましたが、Ubuntu 16.04 LTSサーバー上で私を助けてくれたソリューションになってしまいました
TLDR: landscape-sysinfo を実行して、そのコマンドが終了するまでに時間がかかるかどうかを確認してください。このコマンドはすべてのシステムで利用できるわけではないことに注意してください。(「でも待って、もっとあるのよ…」)
問題のあるマシン上の別のポートで 2 台目の ssh サーバを起動するには、デバッグモードで行います
sudo /usr/sbin/sshd -ddd -p 44321
冗長モードで他のマシンからそのサーバーに接続します
ssh -vvv -p 44321 username@server
私のクライアントは、寝る直前に以下のようなセリフを出力しています
debug1: Entering interactive session.
debug1: pledge: network
ググってもあまり参考にならないが、サーバーログの方がいい
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051
UsePAM yesをUsePAM noに変更すると、この問題が解決されることに気づきました
UseDNSや他の設定とは関係ありませんが、私のシステムではUsePAMだけがこの問題に影響しています
理由がわからないし、副作用がどれなのかわからないのでUsePAMをnoにしておくわけでもないのですが、これで調査を続けられるようになりました
なので、これを答えだと思わずに、まずは何が悪いのかを調べることから始めてみてください
そこで、調べ続けて、sshdをstrace(sudo strace /usr/sbin/sshd -ddd -p 44321)で実行してみました。すると、以下のような結果が得られました
sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385
/etc/update-motd.dの行で怪しくなったのですが、どうやら/etc/update-motd.dに入っているものの結果を待っている処理らしいです
そこで、システムの負荷やパッケージのアップグレードが必要な場合などを含めて、この動的なMessage Of The Dayを生成するすべてのファイルを実行するPAMを抑制するためにcdを/etc/update-motd.dにしてsudo chmod -x *を実行しましたが、これで問題は解決しました
これは「省エネ」なN3150のCPUをベースにしたサーバーで、24時間365日やることがたくさんあるので、これだけのモットデータを集めるのはちょっと無理があったんじゃないかと思います
そのフォルダ内のスクリプトを選択的に有効にして、どれが害が少ないかを確認することにしようかと思いますが、特別にlandscape-sysinfoを呼び出すのは非常に遅く、50-landscape-sysinfoはそのコマンドを呼び出します。これが一番の遅延の原因だと思います
ほとんどのファイルを再有効化した結果、50-landscape-sysinfoと99-esmがトラブルの原因であるという結論に達しました。50-landscape-sysinfoは約5秒、99-esmは約3秒で実行されました。残りのファイルは全部で約2秒
50-landscape-sysinfo と 99-esm のどちらも重要ではありません。50-landscape-sysinfo は興味深いシステム統計を出力し（スペースが足りない場合も！）、99-esm は Ubuntu Extended Security Maintenance に関連したメッセージを出力します
最後に、echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shでスクリプトを作成して、要求に応じてそのプリントアウトを取得することができます
1 Daniel F 2018-11-20
このスレッドはすでに解決策の束を提供していますが、私のはここでは与えられていません =)。だから、ここにあります。私の問題(ラズベリーπにsshでログインするのに約1分かかりました)は、破損した.bash_historyファイルが原因でした。ファイルはログイン時に読み込まれるので、これがログイン遅延の原因となっていました。ファイルを削除すると、ログイン時間は瞬時に通常の状態に戻りました
これが他の何人かの人の助けになることを願っています
1 user3320224 2018-01-03
PAM が /var/log/btmp ファイルを読み込んでいることがわかりました。これが原因で、ログイン時間が 1 分にも達していました。このファイルをクリアすることで問題は解決しました
1 Sylvia Else 2020-04-20
私にとってはGSSAPIが必要で、DNSの逆引きをオフにしたくありませんでした。それは良い考えとは思えなかったので、resolv.confのメインページをチェックアウトしました。私と SSH 接続しているサーバとの間にあるファイアウォールが DNS リクエストを妨害していることがわかりました。結局、私がしなければならなかったことは、SSHしているサーバの resolv.conf にこの行を追加することだけでした
options single-request-reopen
0 Sapan Ganguly 2014-08-28
驚くべきことに、CentOS 7 上の bind のパッケージの更新は、今 /etc/named.conf がパーミッションの問題を持っていたことをログに記載して、名前が壊れました。これは0640で数ヶ月間うまく動いていました。今では 0644 を要求しています。これは named デーモンが ‘named’ ユーザのものであることを意味しています。 named がダウンした状態では、ローカルのウェブサーバからの ssh ログインからページ提供まで、すべてが遅くなり、LAMP アプリの動作も遅くなりました
0 David Ramirez 2016-12-13
私の場合は、ローカルの /etc/hosts ファイルに問題がありました。そのため、ssh は二つの異なる IP (一つは間違ったもの) を試していて、タイムアウトするのに時間がかかっていました
ここではssh -vを使うのが効果的でした
$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.
0 malat 2015-05-21
sshに時間がかかっている場合は、次の手順に従ってください。2つのファイルがあります
- ssh_config
- sshd_config –> は sshd_config で変更されます
115番線のコメントを外すことができます
[root@mycentos ~]# vi /etc/ssh/sshd_config
UseDNS no -> default #UseDNS no –> remove # -> UseDNS no only
sshd ファイルを保存し、sshd サービスを再起動します
[root@mycentos ~]# systemctl restart sshd
そうでない場合は、再度時間をかけて、以下の変更に従ってください
GatewayPorts no
PermitTTY yes
UseDNS no -> line no 115
GSSAPIAuthentication no -> line no 79
sshdサービスを再起動して、sshを取ってみます
[root@mycentos ~]# systemctl restart sshd
0 Chimmu Jhulewala 2020-07-18
