[Debian] SSH: Connection closed by 127.0.0.1

[zwik]

Hallo,

Normaal gesproken draai ik in een screen-sessie een ssh-sessie naar m'n Debian Sparc gebakje. Vandaag wilde ik echter nog een connectie leggen naar die bak maar kreeg de volgende melding:

code:

$ ssh zwik@192.168.1.100
Connection closed by 192.168.1.100

Ik probeerde met de connectie die ik nog heb een SSHD te draaien op een ander poortje. Zelfde restultaat helaas. In de logs kan ik verder helemaal niks over fouten ofzo. Ook heb ik dpkg-reconfigure openssh-server te draaien. Helaas zonder resultaat. De config is gewoon standaard die van Debian en hang verder niet aan het internet.

Wanneer ik ssh -vv 192.168.1.100 draai krijg ik de volgende handel te zien:

code:

OpenSSH_4.3p2, OpenSSL 0.9.7j 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.138.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/zwik/.ssh/identity type -1
debug1: identity file /home/zwik/.ssh/id_rsa type -1
debug1: identity file /home/zwik/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-1
debug1: match: OpenSSH_4.3p2 Debian-1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[e-mail],zlib
debug2: kex_parse_kexinit: none,[e-mail],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[e-mail]
debug2: kex_parse_kexinit: none,[e-mail]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 124/256
debug2: bits set: 499/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Connection closed by 192.168.1.100

Hier lijkt het dus alsof ie geen reply stuurt ofzo. Ik heb verder niks nuttigs op google kunnen vinden hierop. Weten jullie misschien nog iets om het weer werkend te krijgen zonder m'n huidige connectie te verliezen ? .

Ohja, ik draai Debian unstable
Versie nummer van de ssh package weet ik niet (geen idee hoe ik dat opvraag met Debian (shame on me).

[ Voor 3% gewijzigd door zwik op 17-05-2006 19:09 ]

[Spider.007]

Kun je vanaf de bak zelf wel ssh'en naar localhost? Het lijkt gewoon alsof de upgrade niet goed is gegaan; bestaande sessies blijven dan bestaan en nieuwe kunnen niet aangemaakt worden

[BoAC]

Heb je je bak geupdated sinds de laatste start van sshd?

[zwik]

Spider.007 schreef op woensdag 17 mei 2006 @ 19:47:
Kun je vanaf de bak zelf wel ssh'en naar localhost? Het lijkt gewoon alsof de upgrade niet goed is gegaan; bestaande sessies blijven dan bestaan en nieuwe kunnen niet aangemaakt worden

Nee, vanaf localhost krijg ik precies hetzelfde helaas.

BoAC schreef op woensdag 17 mei 2006 @ 20:03:
Heb je je bak geupdated sinds de laatste start van sshd?

De bak is wel geupdate ja. Ik probeer dat weekelijks bij te houden. Paar dagen terug is dat voor het laatst gebeurd. Ik heb wel een update gedraait vandaag maar er zaten geen update voor dit pakket bij .

[Erkens]

zwik schreef op woensdag 17 mei 2006 @ 20:38:
De bak is wel geupdate ja. Ik probeer dat weekelijks bij te houden. Paar dagen terug is dat voor het laatst gebeurd. Ik heb wel een update gedraait vandaag maar er zaten geen update voor dit pakket bij .

Al geprobeerd om de laatste updates terug te draaien?

[zwik]

Ik heb geen idee hoe ik dat moet doen eerlijk gezegd .

[Erkens]

Ik ken debian niet, zelf gebruik ik met mijn slackware doosjes altijd swaret, waarmee je een mooie --rollback optie hebt. Ik kan me niet voorstellen dat debian zoiets niet heeft

offtopic:
Zelf zou ik niet direct alles upgraden zonder het te testen, zeker niet als je niet weet hoe je de upgrade kan terugdraaien

[Candymirror]

Dit had ik voor een tijd terug ook al na een upgrade. Ik heb toen apt-get remove ssh en
dpkg --purge ssh gedaan en vervolgens ssh opnieuw geinstalleerd. Let op bij het removen welke pakketen allemaal worden gedeinstalleerd.

[BoAC]

zwik schreef op woensdag 17 mei 2006 @ 20:38:
[...]

Nee, vanaf localhost krijg ik precies hetzelfde helaas.


[...]

De bak is wel geupdate ja. Ik probeer dat weekelijks bij te houden. Paar dagen terug is dat voor het laatst gebeurd. Ik heb wel een update gedraait vandaag maar er zaten geen update voor dit pakket bij .

Wanneer glibc wordt geupdated en je herstart de huidig-draaiende sshd-daemon niet kun je niet meer connecten De huidig openstaande connecties blijven wel werken. Het herstarten van je sshd-daemon is voldoende om dit op te lossen

[zwik]

Candymirror schreef op donderdag 18 mei 2006 @ 07:49:
Dit had ik voor een tijd terug ook al na een upgrade. Ik heb toen apt-get remove ssh en
dpkg --purge ssh gedaan en vervolgens ssh opnieuw geinstalleerd. Let op bij het removen welke pakketen allemaal worden gedeinstalleerd.

Ik zal het proberen .

BoAC schreef op donderdag 18 mei 2006 @ 09:05:
[...]

Wanneer glibc wordt geupdated en je herstart de huidig-draaiende sshd-daemon niet kun je niet meer connecten De huidig openstaande connecties blijven wel werken. Het herstarten van je sshd-daemon is voldoende om dit op te lossen

Ik had reeds al geprobeerd de service geprobeerd te starten. Helaas zonder resultaat.

Mijn probleem nu is dat ik de connectie kwijt ben. Ik moet dus eerste ergens een monitor vandaan zien te halen welke wel werkt. De monitor die ik gebruik op m'n workstation doet het niet op m'n Sparc .

[zwik]

Nou, ik zit weer met een probleem waar ik niks mee kan. Na packages openssh-server een ssh verwijderd te hebben en de /etc/ssh dir. lukt het me totaal niet meer om het weer opnieuw te installeren
wanneer ik apt-get install ssh doe wil deze openssh-server en ssh installeren. Geen probleem .

Het gaat fout wanneer apt de packages gaat configureren. Hij zegt dat ie /etc/ssh/sshd_config niet kan vinden. Niet zo gek. Die heb ik zelf wegegooit. Op google kan ik nergens vinden hoe ik deze files opnieuw kan laten generen door Debian. Met dpkg-reconfigure lukt het ook niet trouwens.

[DeMoN]

zwik schreef op vrijdag 19 mei 2006 @ 15:37:
Nou, ik zit weer met een probleem waar ik niks mee kan. Na packages openssh-server een ssh verwijderd te hebben en de /etc/ssh dir. lukt het me totaal niet meer om het weer opnieuw te installeren
wanneer ik apt-get install ssh doe wil deze openssh-server en ssh installeren. Geen probleem .

Het gaat fout wanneer apt de packages gaat configureren. Hij zegt dat ie /etc/ssh/sshd_config niet kan vinden. Niet zo gek. Die heb ik zelf wegegooit. Op google kan ik nergens vinden hoe ik deze files opnieuw kan laten generen door Debian. Met dpkg-reconfigure lukt het ook niet trouwens.

Hmm je zit je systeem te f*cken kerel
Definitief verwijderen doe je met dpkg --purge !
Dan gooit hij je configs weg. Wat je nu hebt gedaan is een normale apt-get remove (of dpkg -r ) en handmatig je configfiles getrashed. Je systeem denkt dat die configfiles er nog zijn (die worden niet weggegooid met een apt-get remove of dpkg -r voor evt. later gebruik) en nu wil hij je ssh meuk weer opzetten mbv oude ssh config files. En die zijn er niet!
Wat je moet proberen is ff heel ssh er definitief afgooien en weer reinstallen:

dpkg --purge --force-all <ssh>

[zwik]

Ik vrees dat dat ook niet werkt DeMoN.. Het ding staat al 3 dagen lang een RSA key genereren. Lijkt me iets te lang van het goede. Kan ik aan apt niet gewoon een parameter meegeven waarmee ik force alles default te laten (niet naar configuratie kijken (die weg is))?

edit:

Na een update lijkt ie al wat meer te doen. Ik heb nu wel een sshd_config file gekregen en is bezig een nieuwe host key te genereren. Hopelijk gaat het goed .

[ Voor 26% gewijzigd door zwik op 22-05-2006 20:40 ]

[zwik]

Ik word een beetje moe van nieuwe keys generen (duurt me veels te lang). Is er een manier om keys te laten generen op een andere bak omdat dat veel sneller gaat?

Volgens mij kan dat namelijk niet echt omdat de hostname in de keys verweven zit. Ik heb al met ssh-keygen zitten spelen op een andere machine maar krijg het niet voor elkaar om een andere hostname in de keys te stoppen..

---

Het is inmiddels gelukt om de keys op de bak te krijgen. SSH server start netjes en alles . Nou ben ik helaas weer terug bij af. Na een backup gemaakt te hebben van de keys en (standaard)configuratie probeer ik in te loggen. Ik krijg echter weer precies dezelfde melding

code:

Connection closed by 127.0.0.1

Maakt niet uit vanaf welke host, altijd dezelfde melding. met -vv krijg ik ook exact hetzelfde als wat hierboven al staat.

Tijd om de configuratie om te gooien! Uiteindelijk heb ik dit over gehouden:

code:

Protocol 2
PermitRootLogin no
PasswordAuthentication no
UsePAM yes

Dit werkt op een andere machine perfect. Op deze machine krijg ik nog steeds hetzelfde. Ik heb geen flauw idee waar het aan kan liggen..

[edit]
Ik merk zojuist dat ssh'en naar een andere machine vanaf die brakke ssh machine ook niet lukt . Daar krijg ik hetvolgende:

code:

$ ssh zwik@192.168.1.104
The authenticity of host '192.168.1.104 (192.168.1.104)' can't be established.
RSA key fingerprint is aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.104' (RSA) to the list of known hosts.
RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01
key_verify failed for server_host_key
$

Nou zit ik echt met m'n handen in het haar.

[ Voor 75% gewijzigd door zwik op 23-05-2006 00:54 ]

[daft_dutch]

ik heb nog nooit enkele problemen gehad met debian en ssh.
Maarue zit de sshd niet gewoon in het ssh paket?

Heb je zeer eventueel niet officeele apt sources in je apt sources config?

btw apt-get install --reinstall <package> is de manier om dingen te herinstaleren

[Verwijderd]

Ik heb een soortgelijk probleem met ssh gehad op een ultrasparc met debian unstable. Bij mij kwam het doordat ik mdns in het hosts gedeelte van /etc/nsswitch.conf had gezet. Ik kreeg dezelfde foutmelding toen ik probeerde in te loggen op die bak.

nadat ik mdns er uit had gehaald werkte het weer perfect.

[zwik]

daft_dutch schreef op dinsdag 23 mei 2006 @ 03:00:
ik heb nog nooit enkele problemen gehad met debian en ssh.
Maarue zit de sshd niet gewoon in het ssh paket?

Heb je zeer eventueel niet officeele apt sources in je apt sources config?

btw apt-get install --reinstall <package> is de manier om dingen te herinstaleren

Ik heb dit ondertussen ook geprobeerd, vervolgens purgen en weer opnieuw installeren. Allen zonder resultaat.

Verwijderd schreef op dinsdag 23 mei 2006 @ 10:00:
Ik heb een soortgelijk probleem met ssh gehad op een ultrasparc met debian unstable. Bij mij kwam het doordat ik mdns in het hosts gedeelte van /etc/nsswitch.conf had gezet. Ik kreeg dezelfde foutmelding toen ik probeerde in te loggen op die bak.

nadat ik mdns er uit had gehaald werkte het weer perfect.

Bij mij staat er geen mdns in. Ook weer gewoon een standaard Debian configuratie .

Iedere keer wanneer ik opnieuw installeer gaat deze nieuwe keys maken (wat heel lang duurd). Ik heb dus geprobeerd om keys op een andere machine te maken. Dat is ook gelukt. Alleen komt in de .pub file steeds root@hostname. Mag dit wel? Kan het zijn dat daardoor het niet helemaal goed werkt? Keys generen op de bak zelf duurt namelijk een eeuwigheid. Volgens mij duurde het bij het installeren van die bak niet zo lang namelijk.

[Verwijderd]

Ik heb dan geen verstand SPARC maar check eens welke random device hij gebruikt. /dev/random is vaak de random die door hardware (schijfactiviteit, toestenbord, muis) gegenereed wordt. Als deze leegloopt kan het weleens heeeeeel lang duren eer hij een key gegeneerd heeft. Probeer anders eens /dev/urandom te gebruiken. Deze wordt door de kernel gemaakt en is niet zo super random als /dev/random maar wel genoeg denk ik. Deze loopt iig niet leeg.

[zwik]

Verwijderd schreef op dinsdag 23 mei 2006 @ 12:35:
Ik heb dan geen verstand SPARC maar check eens welke random device hij gebruikt. /dev/random is vaak de random die door hardware (schijfactiviteit, toestenbord, muis) gegenereed wordt. Als deze leegloopt kan het weleens heeeeeel lang duren eer hij een key gegeneerd heeft. Probeer anders eens /dev/urandom te gebruiken. Deze wordt door de kernel gemaakt en is niet zo super random als /dev/random maar wel genoeg denk ik. Deze loopt iig niet leeg.

SSH gebruikt standaard /dev/random en dit is niet aanpasbaar omdat het "onveilig" zou zijn. Ik mijn zoektoch kwam ik tegen om de poolsize in /proc/sys/kernel/random/poolsize te vergroten. Met Vim of echo lukt dit echter niet omdat het kreng continue veranderd (niet de inhoud overigens). Als ik de poolsize zou kunnen vergroten heeft /dev/random meer inhoud zeg maar .

Wanneer ik /dev/random gewoon cat stopt ie na een tijdje ook en druppelt er zo nu en dan wat nieuwe characters binnen. urandom blijft wel doorgaan, helaas is niet mogelijk om eene parameter mee te geven aan ssh om die device te gebruiken.

Volgende vraag is dus: hoe vergroot ik de poolsize? .

[Verwijderd]

sysctl -w kernel.random.poolsize=4096

[zwik]

Daar ben ik weer een keer. Ik heb eindelijk keys maar helaas. Zelfs met nieuwe keys werkt het niet. Ik heb ondertussen ook zelf verschillende malen op verschillende manieren zelf ssh zitten compileren. Allemaal zonder resultaat. What to do next?

[zwik]

Het gok dat het ligt aan libssl (openssl). Aangezien ik niet meer kan connecten met SSL IRC servers. SSH maakt ook gebruikt van libssl. Even uitzoeken hoe ik dat oplos .