SSH giriş bilgilerim neden yavaş?


95

SSH oturumlarında gecikmeler görüyorum. Spesifik olarak, anlıktan çok saniye gecikmelerine kadar bir aralık görebildiğim 2 nokta var.

  1. Ssh komutunu vermek ile giriş istemi almak arasında ve
  2. parola girme ve kabuk yüküne sahip arasında

Şimdi, özellikle sadece burada ssh ayrıntılarına bakıyorum. Açıkçası ağ gecikmesi, dahil olan donanım ve işletim sistemi hızı, karmaşık oturum açma komut dosyaları vb. Gecikmelere neden olabilir. Bağlam için müşteri sistemim olarak çoğunlukla Ubuntu, CentOS ve MacOS X kullanan çok sayıda linux dağıtımına ve bazı Solaris sunucularına ssh. Neredeyse her zaman, ssh sunucusu yapılandırması, işletim sisteminin varsayılan ayarlarından değiştirilmez.

Hangi ssh sunucusu yapılandırmaları ile ilgilenmeliyim? Ayarlanabilecek OS / çekirdek parametreleri var mı? Giriş kabuğu hileci? Vb?


yerel hesap mı kullanıyorsun - Bazen ben pam kimlik doğrulaması ssh ile giriş için bir gecikme ekleyebilir bulmak
Sirex

Genellikle yerel hesaplar. Bazen NIS.
Peter Lyons

Yanıtlar:


122

Belirlemeyi deneyin UseDNSiçin node /etc/sshd_configya /etc/ssh/sshd_config.


7
+1,
ssh'e

2
"Solaris 11 notu: Solaris 11'de UseDNS no ayarı ayarını denedim ve servis başlangıcını bozdu. Servis tarafından tam anlamıyla bir yanıt değil. ." - tarafından comment Keith Hoffman
Sathyajith Bhat

3
IP adresini (ev LAN) kullanarak giriş yaparken kullandığımdan şüpheliydim, ancak bu çözüm sorunumu çözdü. Google hatırı için, hemen sonra olmasına rağmen, gecikmenin "key: /home/mylogin/.ssh/id_ecdsa ((nil))" mesajı (hiçbiri çalışırken ssh -vvv) ile ilgisi yoktu .
Skippy le Grand Gourou

2
Açık yapmak için +1, dosya /etc/ssh/sshd_config! Ben ekleyerek /etc/sshd_configve hiçbir fark görmüyordu!
vyom

1
@SkippyleGrandGourou: Bazı Solaris sürümleri SunSSH adı verilen değiştirilmiş bir OpenSSH kullanıyor ve bu da can sıkıcı uyumsuzluklar içeriyordu. Solaris 11.3, OpenSSH'i geri ekledi ve SunSSH sonunda kaldırılacak ...
Gert van den Berg,

37

ssh -vvvBenzer bir yavaş performansa sahip bir sunucuda çalışırken, burada bir askıda kaldığını gördüm:

debug1: Next authentication method: gssapi-with-mic

Bu /etc/ssh/ssh_configkimlik doğrulama yöntemini düzenleyerek ve yorumlayarak giriş performansını normale döndürdüm. İşte benim /etc/ssh/ssh_configsunucuda ne var :

GSSAPIAuthentication no

Bunu genel olarak sunucuda ayarlayabilirsiniz, böylece GSSAPI'nin kimliğini doğrulamasını kabul etmez. Sadece eklemek GSSAPIAuthentication noiçin /etc/ssh/sshd_configsunucuda ve hizmeti yeniden başlatın.


Bunu, winbind / reklam girişleri yapılandırıldıktan sonra RHEL5 sunucularımda olduğu gibi buldum.
Çad,

Bu benim için bir Ubuntu 14.04 sunucusunda çalışıyor.
Penghe Geng

CentOS 7 için, her iki ayarlamanız gerekir GSSAPIAuthentication nove UseDNS node /etc/ssh/sshd_configdosyaya.
Sunry

19

Benim için suçlu IPv6 çözünürlüğü oldu, zaman aşımına uğradı. (Ev sahibi sağlayıcımda kötü DNS ayarı sanırım.) Bunu yaparak ssh -v, hangi adımın asılı olduğunu gösterdi.

Çözüm seçeneği sshile -4yapmaktır:

ssh -4 me@myserver.com


2
Zaman geçtikçe ve bir şeyler (çok kötü bir şekilde) yavaş yavaş IPV6'ya uydukça, daha fazla çoğumuzun bunu göreceğinden şüpheliyim. Teşekkürler!
sage

1
... ve bu cevap, sorunun bu olduğunu doğrulayan hata ayıklama mesajı olmadan özellikle yararsızdır.
EP,

SSH dualstack arayüzlerini dinlerken ve ilk giriş yaptığımda ilk kontrol ettiğim şeyi bu benim için çok sık rastlanan bir sorun, ancak beklenenden daha fazla zaman alıyor.
Mogget

IPv4'ü varsayılan yapmak yerine IPv6'yı düzeltebileceğimiz bir şans var mı?
msrd0

Bu muhtemelen UseDNS’in cevap vermemesinin sebebidir. -vvv kullanmak sadece debug2: resolving "thing.net.au" port 22hatasız duraklatmayı gösterir , ancak bunun DNS IPv6 sorunu olduğunu gösteren -4 ile olmaz.
27'de

16

Systemd ile giriş, bazı güncellemelerin ardından logind ile dbus iletişimine bağlı kalabilir, ardından logind komutunu yeniden başlatmanız gerekir.

systemctl restart systemd-logind

Bunu debian 8'de, arch linx'te ve bir suse listesinde gördüm.


1
Vay canına, şimdi bu suçlu oldu! Çok teşekkürler!
mahatmanich

Benim için aynı. İlk önce olası tüm DNS ve SSH konularını ekarte etmek biraz zaman aldı. Not: Sorun yavaş sudo için de geçerliyse, önce bunu deneyin.
Michael,

RHEL6'dan RHEL7'ye bazı yerinde güncellemeleri yeni bitirdim ve bu sorunu farkettim. Bu cevap aynı zamanda sorunumu da çözdü.
user53029

çok teşekkür ederim, bir cazibe gibi çalışır.
Bảo Nam

9

Her zaman başlayabilir sshile -vşu anda yapılıyor ne görüntüleyen seçeneği.

$ ssh -v you@host

Verdiğiniz bilgilerle yalnızca bazı müşteri tarafı yapılandırmaları önerebilirim:

  • Parolaları elle girdiğinizi yazdığınızdan, mümkünse genel anahtar kimlik doğrulamasını kullanmanızı öneririm. Bu sizi bir hız darboğazı gibi temizler.

  • Ayrıca, X iletmeyi -xve kimlik doğrulama iletmeyi devre dışı bırakabilirsiniz -a(bunlar zaten varsayılan olarak devre dışı olabilir). Özellikle X iletmeyi devre dışı bırakmak, müşterinizin sshkomut için bir X-sunucusu başlatması gerektiğinde (örneğin OS X altında) size büyük bir hız artışı sağlayabilir .

Her şey, nerede ve ne zaman yaşayacağınız ne tür gecikmelere bağlı.


Ayrıntı hakkında iyi ipucu, daha fazla v sahip alarak da artırabilirsiniz. 3 IIRC'ye kadar.
Eylül'de

7

2. noktaya gelince, burada sunucuyu değiştirmeyi gerektirmeyen veya kök / yönetici ayrıcalıklarına sahip olmayı gerektirmeyen bir cevap vardır.

Aşağıdaki "user ssh_config" dosyanızı düzenlemeniz gerekir:

vi $HOME/.ssh/config

(Not: yoksa, $ HOME / .ssh dizinini oluşturmalısınız.)

Ve Ekle:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Gerekirse bunu ev sahibi bazında yapabilirsiniz :) örnek:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

IP adresinin sunucunuzun IP adresiyle aynı olduğundan emin olun. Harika bir avantaj, şimdi ssh'nin bu sunucu için otomatik tamamlamayı sağlayacağıdır. Yani ssh lin+ yazabilirsiniz Tabve otomatik olarak tamamlaması gerekir ssh linux-srv.


4

/etc/resolv.confBu dosyada listelenen DNS sunucusunun iyi çalıştığından emin olmak için sunucuyu kontrol edin ve çalışmayan herhangi bir DNS'yi silin.

Bazen çok yardımcı olur.


2

Bahsedilen DNS sorunlarının yanı sıra, birçok NFS bağlantısı olan bir sunucuya giriyorsanız, quotakomut, bağlı olmayan tüm dosya sistemlerinde kullanımınızı / kotanızı denetlerken , parola ile bilgi istemi arasında bir gecikme olabilir noquota. Solaris sistemlerinde /etc/profilebunu varsayılan olarak görebilir ve çalıştırarak atlayabilirsiniz touch $HOME/.hushlogin .


1

İyi çalışmak.

# 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 hayır OpenIndiana ile çalışmıyor !!!

Tüm seçenekler için "man sshd_config" bölümünü okuyun.

Sunucunuz çözemiyorsa "LookupClientHostnames no"


1

Yukarıdaki cevapların hiçbiri işe yaramazsa ve dns geriye doğru arama problemleriyle karşı karşıya kalırsanız, nscd(isim servisi önbellek arka planının) kurulup kurulmadığını da kontrol edebilirsiniz .

Sorun buysa, dns önbelleğiniz yoktur ve ana makinenizde bulunmayan bir ana bilgisayar adını her sorguladığınızda, soruyu önbelleğinize bakmak yerine ad sunucunuza gönderirsiniz.

Yukarıdaki seçeneklerin hepsini denedim ve çalışan tek değişiklik başladı nscd.

Ayrıca /etc/nsswitch.confhosts dosyasını kullanmak için dns sorgusu çözünürlüğü oluşturmak için sırayı doğrulamanız gerekir .


1

Bu muhtemelen yalnızca Debian paket sağlayıcılarından biri tarafından yazılmış user-group-modes.patch'i içeren Debian / Ubuntu OpenSSH'ye özgüdür. Bu düzeltme eki, ~ / .ssh dosyalarının, dosya ile aynı gidere sahip yalnızca bir kullanıcı olması durumunda, grubun yazılabilir biti ayarlanmış (g + w) olmasını sağlar. Yama'nın secure_permissions () fonksiyonu bu kontrolü yapar. Kontrolün aşamalarından biri getpwent () işlevini kullanarak her bir passwd girişinden geçmek ve girişin gidini dosyanın gidonuyla karşılaştırmaktır.

Çok girişli ve / veya yavaş NIS / LDAP kimlik doğrulaması olan bir sistemde bu kontrol yavaş olacaktır. nscd, getpwent () çağrılarını önbelleğe almaz, bu nedenle sunucu yerel değilse, her passwd girişi ağ üzerinden okunur. Bunu bulduğum sistemde, her ssh çağrısı veya sisteme giriş yapılması için yaklaşık 4 saniye eklendi.

Düzeltme işlemi tüm dosyaların üzerine yazılabilir biti ~ / .ssh yaparak kaldırmaktır chmod g-w ~/.ssh/*.


1

Ben systemd-logind.service yeniden başlatmanın sadece birkaç saatliğine sorunu çözdüğünü öğrendim. Sshd_config dosyasında UsePAM'i evet'den hayır'a değiştirmek, motd artık görüntülenmese de hızlı girişlerle sonuçlandı. Güvenlik sorunları hakkında yorumlar?


Burada başka bir öneride bulunmuştum ve Samba4 etkinleştirme sunucumdaki sorunu gideren tek şey bu ... TEŞEKKÜRLER!
Deven Phillips,

UYARI: 'UsePAM no', Red Hat Enterprise Linux'ta desteklenmez ve birkaç soruna neden olabilir.
bbaassssiiee

1

DNS çözümlerinin ssh giriş bilgilerinizi yavaşlattığını gösteren tüm yanıtları tamamlamak için, bazen bir güvenlik duvarı kuralları yoktur. Örneğin, tüm INPUT paquet'lerini varsayılan olarak DROP

iptables -t filter -P INPUT DROP

o zaman ssh portu ve DNS isteği için INPUT'u kabul etmeniz gerekir.

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

1

ssh -vvv en az 20 saniye boyunca terminali almaya çalışırken sisteme takılana kadar bağlantı gerçekten iyi gitti:

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 Sunucuda bir yaptıktan sonra tekrar anında bağlantı vardı!

Bu debian8'deydi ! Yani sistemd burada sorun oldu!

Not: Bastien Durel bu konuya zaten bir cevap verdi, ancak hata ayıklama bilgisine sahip değil. Umarım bu birine yardımcı olur.


Ben RHEL7 asılı "interaktif oturumu girme" ile aynı sorunu (CentOS 7) vardı ve dışarı yorum yaparak bunu çözdü session [default=1] pam_lastlog.so nowtmp showfailediçinde /etc/pam.d/postlogin. Görünüşe göre lastlog dosyasını güncellemek konteyner tabanlı OpenVZ VPS'imde inanılmaz derecede yavaştı.
Justin,

1

Son zamanlarda yavaş ssh girişlerinin başka bir nedenini buldum.

Bile Sahip UseDNS noiçinde /etc/sshd_config, sshd eğer hala ters DNS aramalarını gerçekleştirebilir /etc/hosts.denygibi bir giriş vardır:

nnn-nnn-nnn-nnn.rev.some.domain.com

Sisteminizde yüklü DenyHosts varsa bu olabilir .

Birisi DenyHosts'un bu tür bir giriş yapmaktan kaçınmasını nasıl sağlayacağını bilmesi harika olurdu /etc/hosts.deny.

DenyHosts SSS sayfasına bağlantıların nasıl kaldırılacağı ile ilgili bir link /etc/hosts.deny- bkz . DenyHosts'un engellediği bir IP adresini nasıl kaldırabilirim?


1

Tercih edilen ad çözümleme yönteminin ana bilgisayar dosyası ve ardından DNS olmadığını görebiliriz.

Örneğin, bu normal yapılandırma olacaktır:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

İlk olarak, hosts dosyasına ulaşıldı (seçenek: dosyalar) ve ardından DNS (seçenek: dns), ancak başka bir ad çözümleme sistemi eklendiğini ve bu işlemlerin yapılmadığını ve ters çözümlemede yavaşlamaya neden olduğumuzu görüyoruz.

Ad çözümleme sırası doğru değilse, şu adresten değiştirebilirsiniz: /etc/nsswitch.conf

Çıkarılan kaynak: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html


1

Tüm cevapları denedim ama hiçbiri işe yaramadı. Sonunda sorunumu öğrendim:

önce koşarım sudo tail -f /var/log/auth.log böylece ssh'in logosunu görebiliyorum sonra başka bir oturumda koş ssh 172.16.111.166ve beklediğimi fark ettim

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

Aradıktan sonra bu satırı / etc / ssd / ssh_config içinde buldum

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Ben yorum yaptım ve gecikme gitti


1

Not: Bu bir "Nasıl hata ayıklanır" olarak başladı, öğretici, ancak bir Ubuntu 16.04 LTS sunucusunda bana yardımcı olan bir çözüm oldu .

TLDR : Çalıştırın landscape-sysinfove bu komutun tamamlanması uzun zaman alıyor mu kontrol edin; Yeni bir SSH girişine sistem bilgisi çıktısı. Bu komutun tüm sistemlerde mevcut olmadığını unutmayın, landscape-commonpaket yükler. ("Ama bekleyin, dahası var ...")


Makinede sorunu olan başka bir bağlantı noktasında ikinci bir ssh sunucusu başlatın, bunu hata ayıklama modunda yapın; bu işlem çatal yapmaz ve hata ayıklama iletileri yazdırır:

sudo /usr/sbin/sshd -ddd -p 44321

ayrıntılı modda başka bir makineden bu sunucuya bağlanın:

ssh -vvv -p 44321 username@server

Müşterim uyumaya başlamadan hemen önce aşağıdaki satırları çıkarır:

debug1: Entering interactive session.
debug1: pledge: network

Google, gerçekten yararlı değil ancak sunucu günlükleri daha iyi:

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

Ben değiştiğinde fark UsePAM yesetmek UsePAM nosonra bu sorun giderilmiştir.

UseDNSHerhangi bir ayar ile ilgili değil , sadece UsePAMbu sorunu sistemimde etkiler.

Neden hiçbir ipucu var, ve ben de gitmiyorum UsePAMde noben yan etkiler olan bilmediğimizden, ama bu beni araştırmaya devam etmenizi sağlar.

Lütfen bunun bir cevap olduğunu düşünmeyin, ancak neyin yanlış olduğunu bulmaya başlamak için ilk adım.


Bu yüzden araştırmaya devam ettim ve ( ) sshdile koştum . Bu, aşağıdakileri sağladı:stracesudo 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

Çizgi /etc/update-motd.dbeni şüpheli yaptı, görünüşe göre süreç içinde olan şeylerin sonucunu bekliyor/etc/update-motd.d

Bu yüzden cd'içine d /etc/update-motd.dve ran sudo chmod -x *PAM bu dinamik oluşturmak tüm dosyaları çalıştırmak engellemek amacıyla Message Of The Daysistem yükünü içerir ve paketler gerekirse yükseltilmiş, ve bu sorunu çözülecek olan.

Bu, 7/24 yapılacak çok işi olan "enerji tasarruflu" N3150 CPU'yu temel alan bir sunucudur, bu yüzden tüm bu sakal verilerinin toplanmasının çok fazla olduğunu düşünüyorum.

Bu klasördeki komut dosyalarını seçerek etkinleştirmeye başlayabilir, hangisinin daha az zararlı olduğunu, ancak özel olarak arama landscape-sysinfoyapmak çok yavaştır ve 50-landscape-sysinfobu komutu çağırır. En büyük gecikmeye neden olanın bu olduğunu düşünüyorum.

Dosyaların çoğu yeniden etkinleştirdikten sonra sonuca vardık 50-landscape-sysinfove 99-esmbenim sorunlarım sebebi idi. 50-landscape-sysinfoyürütmek için yaklaşık 5 saniye sürdü ve 99-esmyaklaşık 3 saniye. Kalan tüm dosyalar yaklaşık 2 saniyedir.

Ne 50-landscape-sysinfove 99-esmçok önemlidir. 50-landscape-sysinfoilginç sistem istatistiklerini yazdırır (ve az yer kaplıyorsanız!) ve 99-esmilgiliUbuntu Extended Security Maintenance

Sonunda echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shistek üzerine bir senaryo oluşturabilir ve bu çıktıyı alabilirsiniz.


1

Bu iş parçacığı zaten bir sürü çözüm sağlıyor, ancak benimki burada verilmez =). İşte burada. Sorunum (benim ahududu pi içine ssh giriş için yaklaşık 1 dakika sürdü), bozuk bir .bash_history dosyası nedeniyle oldu. Dosya giriş sırasında okunduğu için bu giriş gecikmesine neden oluyordu. Dosyayı çıkardıktan sonra, giriş zamanı anlık gibi normale döndü.

Umarım bu başkalarına da yardımcı olur.


0

Benim için GSSAPI'ye ihtiyacım vardı ve ters DNS aramalarını kapatmak istemedim. Bu iyi bir fikir gibi görünmüyordu, bu yüzden resolv.conf ana sayfasını kontrol ettim. Görünüşe göre, ben ve SSH'nin istediğim sunucular arasındaki bir güvenlik duvarının DNS isteklerini engellediği, çünkü güvenlik duvarının beklediği şekilde olmadıkları ortaya çıktı. Sonunda tek yapmam gereken, SSHing kullandığım sunuculardaki resolv.conf dosyasına bu satırı eklemek oldu:

options single-request-reopen


0

Dikkat çekici bir şekilde, CentOS 7'deki bir bağlama güncellemesi şimdi /etc/named.conf dosyasının izin sorunu olduğunu belirterek, günlüğe kaydedilmiş bir isim verdi. 0640 ile aylarca iyi çalışmıştı. Şimdi 0644'ü istiyor. Bu, adlandırılmış arka plan programının 'adlandırılmış' kullanıcıya ait olduğu anlamına geliyor.

Adlandırılmış olarak, her şey yavaştı, ssh girişlerinden yerel web sunucusundan sayfa sunumuna, yavaş LAMP uygulamalarını vb.


0

Benim için yerel /etc/hostsdosyamda bir sorun vardı . Bu yüzden sshsonsuza kadar zaman aşımına uğrayan iki farklı IP deniyordu (biri yanlış).

ssh -vBurada hile kullanarak yaptı:

$ 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.

/etc/hostsSunucunun?
Daniel F
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.