[Debian] SSH werkt niet als dns server aan staat.

[Verwijderd]

Ik heb een netwerkje [192.168.0.0/24] waarop o.a. 2 debian systemen aangesloten zijn.

code:

pc1: 
  192.168.0.1 
  Woody[testing]
  kernel 2.4.16
  sshd bind9 etc.
  master nameserver
pc5: 
  192.168.0.5 
  Potato[stable] 
  kernel 2.2.19
  sshd bind etc.
  slave nameserver

het nameserver gedoe werkt perfect!!!!
alleen als ik nu vanaf pc1 naar pc5 ssh....

code:

compukid@pc1:~$ ssh 192.168.0.5
ssh_exchange_identification: Connection closed by remote host

Eerst werkte 't wel....[en waarschijnlijk als ik 't dns gedoe uit zet ook]
de dns records voor beide pc's:

code:

ns1     A   192.168.0.1
        MX  10 mail2
        HINFO   "i686" "Linux 2.4.16"
        TXT "The first name server"
gw      CNAME   ns1
pc1     CNAME   ns1
mail2       CNAME   ns1
www2        CNAME   ns1
ftp2        CNAME    ns1

pc5     A   192.168.0.5
        MX  10 mail2
        HINFO   "i486" "Linux 2.2.19"
ns2     CNAME   pc5

[deadinspace]

Zorg je er ook voor dat de nameservers je IPs reverse resolven? Zo nee, dan is dat hws de oorzaak.

[Verwijderd]

Op zaterdag 22 december 2001 22:49 schreef deadinspace het volgende:
Zorg je er ook voor dat de nameservers je IPs reverse resolven? Zo nee, dan is dat hws de oorzaak.

yep dat werkt...

[Verwijderd]

iemand een idee wat de foutmelding betekent?

[Tha_Butcha]

'connection closed by remote'

lijkt mij eerder dat de sshd niet goed geconfigged is, omdat ie weigert te connecten. Daarbij is het over het algemeen dat als ze niet eens op ip kunnen connecten, dat het aan de niet goed geconfigde service ligt, en niet aan de nameserver o.i.d.

Dus kijk of op die pc5, wel ssh goed draait, open staat, pc1 allowed etc.

Het beste is te beginnen gewoon een keer te proberen te connecten vanaf pc5 naar zichzelf
dus zoiets doen:

[pc-5]$ ssh 127.0.0.1

doet dat het
dan een nmap vanaf pc1 (zou moeten laten zien dat 22: ssh open staat)
daarna kan je dus volgens jou niet connecten naar pc5

dus dan wordt het checken of ssh wel andere computers toelaat, staat pc1 in $HOME/.ssh/known_hosts bijv.

moet je ff de manpages over known_hosts en keygen, en alle links daarin ff over doorploegen

[igmar]

iemand een idee wat de foutmelding betekent?

De melding betekend dat het systeem dat connectie wil maken dat niet mag volgens de access lijst.(de server dropped de connectie voordat de keys uitgewisseld worden). De poster dient dus eens in zin /etc/hosts.allow/deny te gaan kijken.

[_JGC_]

En in hosts.deny vind je standaard:

ALL:PARANOID

ofwel: gaat voor geen meter werken als je geen canonical DNS namen gebruikt
Ik heb er een # voor gezet en nu kan ook een xs4all ADSL gebruiker weer met pop3 connecten.

[Verwijderd]

Op zondag 23 december 2001 22:39 schreef _JGC_ het volgende:
En in hosts.deny vind je standaard:

ALL:PARANOID

ofwel: gaat voor geen meter werken als je geen canonical DNS namen gebruikt
Ik heb er een # voor gezet en nu kan ook een xs4all ADSL gebruiker weer met pop3 connecten.

Hmzz, dat lijkt me niet de meest verstandige manier van oplossen.
Je zet nu alle services die tcpwrapper gebruiken open voor de hele wereld. Zet er dan ALL: ALL in en in je /etc/hosts.allow naam_van_pop3_deamon:ALL of desnoods voor alle XS4all IP's zet je het open.

PARANOID gaat inderdaad boven /etc/hosts.allow.

Zie ook "man 5 hosts_access".

[Verwijderd]

[b]Op zondag 23 december 2001 21:09 schreef
Het beste is te beginnen gewoon een keer te proberen te connecten vanaf pc5 naar zichzelf
dus zoiets doen:

[pc-5]$ ssh 127.0.0.1

Dat werkt!!!

dan een nmap vanaf pc1 (zou moeten laten zien dat 22: ssh open staat)

port 22 staat open volgens nmap

daarna kan je dus volgens jou niet connecten naar pc5
dus dan wordt het checken of ssh wel andere computers toelaat,

vanaf pc2 en pc4 kan ik ssh'en naar pc5....maar vanaf pc1 nogsteeds niet.

[Verwijderd]

als ik op beide pc's bind stop....kan ik opeens wel ssh'en van pc1 naar pc5..

als ik op pc1 of pc5 bind heb lopen....kan ik niet meer ssh'en van pc1 naar pc5...

zal 't dan toch met m'n dns gedoe te maken hebben?

[_JGC_]

Op zondag 23 december 2001 22:59 schreef nelske het volgende:

[..]

Hmzz, dat lijkt me niet de meest verstandige manier van oplossen.
Je zet nu alle services die tcpwrapper gebruiken open voor de hele wereld. Zet er dan ALL: ALL in en in je /etc/hosts.allow naam_van_pop3_deamon:ALL of desnoods voor alle XS4all IP's zet je het open.

PARANOID gaat inderdaad boven /etc/hosts.allow.

Zie ook "man 5 hosts_access".

iptables doet z'n werk ook goed. Alle poorten die ik open heb staan mag iedereen wel op. Ik vind het wel makkelijk als je de ene keer op HCCNet, de andere keer op FreeAccess, dan weer SurfNet, dan weer sjello, etc altijd op die poorten kan connecten. Tis tenslotte alleen maar SSH, POP3, SMTP en WWW, de rest is potdicht

[Verwijderd]

Mjah, ik ben iemand die graag het zekere voor het onzekere neemt

Dan wil het dus wel eens voor komen, dat bepaalde dingen dubbel beveiligd zijn.
Zo werk ik met tcpwrapper support zo veel als mogelijk is en daarnaast met de firewall.
Mocht het ene dan om een mistereuze reden (die ik zo ff niet kan bedenken, maar goed )niet meer werken, dan vangt het andere het altijd nog op

[Verwijderd]

Zou 't aan de CNAME tags kunnen liggen?

[Dim]

Op deze manier kan je niet echt zien wat er nou fout gaat met ssh. Probeer eens:

ssh -v 192.168.0.5

dan krijg je een hele berg verbose output, en daaraan kan je meestal direkt zien waar het precies fout gaat.

Je kunt ook aan de server kant debuggen, maar dat is wat lastiger...

[Verwijderd]

Op dinsdag 25 december 2001 13:56 schreef Dim het volgende:
Op deze manier kan je niet echt zien wat er nou fout gaat met ssh. Probeer eens:

ssh -v 192.168.0.5

dan krijg je een hele berg verbose output, en daaraan kan je meestal direkt zien waar het precies fout gaat.

Je kunt ook aan de server kant debuggen, maar dat is wat lastiger...

code:

OpenSSH_3.0.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 1000 geteuid 0 anon 1
debug1: Connecting to 192.168.0.5 [192.168.0.5] port 22.
debug1: temporarily_use_uid: 1000/1000 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 1000/1000 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/compukid/.ssh/identity type -1
debug1: identity file /home/compukid/.ssh/id_rsa type -1
debug1: identity file /home/compukid/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x80633cc(0x0)

[Thc_Nbl]

Is het niet zo dat je key in je home dir staat anders is dat de key die hij behoort te hebben.

debug1: identity file /home/compukid/.ssh/id_dsa type -1

haal eens je .ssh web ( backup hem ) !!

en probeer opnieuw.

je probleem is zeker gekomen na een apt-get upgrade

suc6

[Verwijderd]

en als ik ssh van pc5 naar pc1:

code:

SSH Version OpenSSH-1.2.3, protocol version 1.5.
Compiled with SSL.
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: ssh_connect: getuid 1000 geteuid 1000 anon 1
debug: Connecting to 192.168.0.1 [192.168.0.1] port 22.
debug: Connection established.
debug: Remote protocol version 1.99, remote software version OpenSSH_3.0.1p1
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host '192.168.0.1' is known and matches the host key.
debug: Encryption type: 3des
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Doing password authentication.

[Verwijderd]

Op dinsdag 25 december 2001 14:24 schreef Thc_Nbl het volgende:
Is het niet zo dat je key in je home dir staat anders is dat de key die hij behoort te hebben.

debug1: identity file /home/compukid/.ssh/id_dsa type -1

haal eens je .ssh web ( backup hem ) !!

en probeer opnieuw.

je probleem is zeker gekomen na een apt-get upgrade

suc6

typo?

het probleem is niet ontstaan na een apt-get upgrade oid maar na het starten van de nameservers. Als ik die uitzet kan ik wel ssh'en.

Ik zal m'n configs van m'n nameservers anders wel tarren...is dat handig?

[Verwijderd]

Hmm, heb je niet je hostnames gewijzigd op die DNS van PC1 ?
Lijkt erop dat je misschien wel kan connecten maar dat er bij het resolven van de naam of ip van PC5 wat fout gaat.

Als je eens telnet vanaf PC1 naar PC5 porrt 22 en dat werkt...(telnet 192.168.0.5 22) je krijgt dan alleen je SSH server versie te zien. Dan weet je in ieder geval dat je TCP connectie werkt. (dat zal al wel gezien de bovenstaande posts).

Probeer eens op je PC1 in je $HOME/.ssh/ directory
in de known_hosts of known_hosts2 file te zoeken naar naam/ip van PC5 en verwijder die entries. (bijna hetzelfde als wat Thc_Nbl bedoelt )

Probeer daarna nog eens te connecten...

[Verwijderd]

Op dinsdag 25 december 2001 22:34 schreef Minotaur het volgende:
Hmm, heb je niet je hostnames gewijzigd op die DNS van PC1 ?
Lijkt erop dat je misschien wel kan connecten maar dat er bij het resolven van de naam of ip van PC5 wat fout gaat.

Als je eens telnet vanaf PC1 naar PC5 porrt 22 en dat werkt...(telnet 192.168.0.5 22) je krijgt dan alleen je SSH server versie te zien. Dan weet je in ieder geval dat je TCP connectie werkt. (dat zal al wel gezien de bovenstaande posts).

ik krijg dan enkel de messages t/m de escape character...
versie niet....
al ik het op pc5 doe krijg ik dat wel...

Probeer eens op je PC1 in je $HOME/.ssh/ directory
in de known_hosts of known_hosts2 file te zoeken naar naam/ip van PC5 en verwijder die entries. (bijna hetzelfde als wat Thc_Nbl bedoelt )

Probeer daarna nog eens te connecten...

heb ik geprobeerd...no difference

[Verwijderd]

De config's van beide ssh's en bind's heb ik beschikbaar gemaakt op de via de volgende link:
http://www.driebergenweb.org/ssh_bind_probleem_cofigs.tgz
let niet op de typo in de filename

[Verwijderd]

Op woensdag 26 december 2001 14:43 schreef compukid het volgende:

ik krijg dan enkel de messages t/m de escape character...
versie niet....
al ik het op pc5 doe krijg ik dat wel...

Hmmm dat vind ik heel vreemd, je zou namelijk altijd iets te zien moeten krijgen. ie.

--[snip]-----------------
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_2.9p2

Protocol mismatch.
Connection closed by foreign host.
--[snip]-----------------

Heb je niet ergens firewall rules -per ongeluk- aan staan waardoor het niet werkt ? Is mij ook vaak zat overkomen.


Verder kon ik vrij weinig in je configuratie files vinden; behalve dat het misschien verstandig is om in je sshd_config files --> Protocol 2
te zetten, dat is een stuk veiliger dan ssh protocol 1. Maar dat heeft verder niks met je probleem te maken

[Verwijderd]

Sinds wanneer wordt er een firewall gestart bij 't uitvoeren van '/etc/init.d/bind9 start'(pc1) of '/etc/init.d/bind start'(pc5) ?
ik heb helemaal geen firewall gedoe aan staan....

ik denk dat het met m'n config van m'n dns te maken heeft...
Weet iemand hoe ik een zone file kan maken zonder het gebruik van de CNAME tags?
Wat zit er fout in m'n zone files????

[igmar]

code:

ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x80633cc(0x0)

Voor de tweede keer : kijk je hosts.allow / hosts.deny naar. Het probleem zit hem toch in die richting.

tweede probleem kan ReverseMappingCheck wezen in je sshd_config, maar dat staat standaard uit.

[Verwijderd]

ik heb in m'n hosts.deny en m'n hosts.allow gekeken...niets te zien....
ik denk ook niet dat daar 't probleem zit. waarom zou die dan wel doen als m'n nameservers uit staan?

[Verwijderd]

Ik heb de oplossing gevonden
Het probleem was idd de zone file.
ik heb nu iets staan van:

code:

pc1     A     192.168.0.1
ns1     CNAME pc1

het was ongeveer zo:

code:

ns1     A     192.168.0.1
pc1     CNAME ns1

/me bedankt iedereen voor z'n hulp, en wenst iedereen een prettig 2002