Hosts.allowya da
hosts.deny` kullanmıyorum, dahası SSH windows makinemden çalışıyor (aynı dizüstü bilgisayar, farklı sabit disk) ama Linux makinemden çalışmıyor.
ssh -vvv root@host -p port
gives:
OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer
Windows makinede her şey iyi çalışıyor, bu yüzden güvenlik günlüklerini kontrol ettim ve oradaki satırlar aynı, sunucu iki farklı "makineye" farklı davranmıyor ve her ikisine de ortak anahtar kimlik doğrulaması yoluyla izin veriliyor.
Bu da, bunun yerel ArchLinux dizüstü bilgisayarımla ilgili bir sorun olması gerektiği sonucuna götürüyor... ama ne?
[torxed@archie ~]$ cat .ssh/known_hosts
[torxed@archie ~]$
Yani sorun bu değil.
[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Güvenlik duvarı ayarları ile çakışma yok (şimdilik)...
[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------ 2 torxed users 4096 Sep 3 2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw------- 1 torxed users 1679 Sep 3 2013 id_rsa
-rw-r--r-- 1 torxed users 403 Sep 3 2013 id_rsa.pub
-rw-r--r-- 1 torxed users 170 May 11 11:21 known_hosts
İzinler iyi görünüyor (sunucuda da aynı) ... Ayrıca `/etc/ssh/ssh_config' yapılandırması yapmadan denedim, istemcide aynı hatayla sonuçlanan çok sayıda otomatik yapılandırma dışında aynı sonuçla karşılaştım.
Herhangi bir "dış" faktörü elediyseniz, aşağıdaki adımlar dizisi genellikle daraltmaya yardımcı olur. Bu, sorunuza doğrudan yanıt vermese de, hatanın nedenini bulmanıza yardımcı olabilir.
sshd
sorununu gidermeBu tür durumlarda genellikle çok yararlı bulduğum şey sshd
yi daemonize olmasına izin vermeden başlatmaktır. Benim durumumdaki sorun ne syslog
ne de auth.log
dosyalarının anlamlı bir şey göstermemesiydi.
Terminalden başlattığımda şunu elde ettim:
# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.
Çok daha iyi! Bu hata mesajı neyin yanlış olduğunu görmemi ve düzeltmemi sağladı. Günlük dosyalarının hiçbiri bu çıktıyı içermiyordu.
NB: en azından Ubuntu'da $(which sshd)
, sshd'nin mutlak yol gereksinimini karşılamak için en iyi yöntemdir. Aksi takdirde şu hatayı alırsınız:
sshd re-exec requires execution with an absolute path. P 10222
, sshd
nin yapılandırma dosyasını geçersiz kılarak bu alternatif bağlantı noktasını dinlemesini sağlar - bu, potansiyel olarak çalışan sshd
örnekleriyle çakışmaması içindir. Burada boş bir port seçtiğinizden emin olun.
Son olarak: alternatif porta bağlanın (ssh -p 10222 user@server
).
Bu yöntem, kimlik doğrulama sorunları veya diğer türler olsun, sorunları bulmamda bana birçok kez yardımcı oldu. Stdouta gerçekten ayrıntılı çıktı almak için
$(which sshd) -Ddddp 10222kullanın (ayrıntı düzeyini artırmak için eklenen
ddye dikkat edin). Daha fazla hata ayıklama iyiliği için
man sshd`yi kontrol edin.
Bu hatanın sunucuya yapılan ssh oturumlarının aşılmasından kaynaklandığını buldum. Bağlanmaya çalışan ana bilgisayarları buldum ve tüm istemcilerin tüm oturumlarını sonlandırdım. Tüm oturumları temizledikten sonra sorun çözüldü.