[Debian] SSH probleem met connecten

[we_are_borg]

Ik heb in een vmware omgeving Debian geïnstalleerd en mijn netwerk ingesteld ip nummer is 192.168.1.113. Hierna heb ik het volgende gedaan:

1. apt-get update
2. apt-get upgrade
3. apt-get install ssh

Bij 3 heb ik aangegeven dat ik alles wil installeren wat hij nodig heeft. Na downloaden wil ik een connectie maken via mijn normale pc dit lukt niet ik krijg connection refused te zien. Op mijn Linux systeem het volgende gedaan

code:

ssh naam@localhost

Dit werkt in één keer en ik kan het systeem besturen. Nu probeer ik het volgende:

code:

ssh -v naam@192.168.1.113

Ik krijg nu te zien ssh: connect to host 192.168.1.1.113 port 22: Connection refused

Ik heb al verschillende instellingen geprobeerd ook in de allow file opgenomen dat sshd altijd een connectie mag toestaan, maar dit heeft niet geholpen. Momenteel staat de oude config file weer terug dus alles is weer standaard.

Ik zou graag willen weten wat er fout gaat met ssh ik heb dit nog nooit mee gemaakt.

[BarthezZ]

Uhmm, het is openssh-server wat je moet installen?

[we_are_borg]

Die wordt geïnstalleerd op het moment dat je apt-get install ssh doet en dan Yes op alles doet aangezien het een vereiste packet is.

[jordz.]

/etc/hosts.allow ? beter lezen
Ook sshd: ALL al geprobeerd?

[ Voor 59% gewijzigd door jordz. op 08-08-2009 20:11 ]

[we_are_borg]

jordz. schreef op zaterdag 08 augustus 2009 @ 20:10:
/etc/hosts.allow ? beter lezen
Ook sshd: ALL al geprobeerd?

Die heb ik ook al geprobeerd ook met ip nummers erbij maar dit mocht ook niet baten.

[sunoke]

Ssh server herstarten?

code:

/etc/init.d/sshd restart

Draait sshd wel?

code:

ps aux | grep ssh

[we_are_borg]

Herstarten heb ik al een paar keer gedaan, ja ssh draait anders kan ik via ssh naam@localhost niet connecten het gaat alleen fout als ik connect naar ip adres.

[Verwijderd]

Al in iptables gekeken en "netstat -tap" gedaan? Heb je ~/.ssh al geleegd op de client?

"ja ssh draait anders kan ik via ssh naam@localhost niet connecten " -> localhost != 192.168.1.33 lijkt mij? Ah je bedoelt dat je vanuit je VM naar localhost kan connecten.

ssh username@192.168.1.33 werkt ook niet?

Doe een poortscan met nmap op je hele netwerk:
nmap -v -A 192.168.1.*

[ Voor 12% gewijzigd door Verwijderd op 08-08-2009 21:06 ]

[we_are_borg]

Verwijderd schreef op zaterdag 08 augustus 2009 @ 21:05:
Al in iptables gekeken en "netstat -tap" gedaan? Heb je ~/.ssh al geleegd op de client?

Ja heb ik gedaan (zowel iptables als ~/.shh) ook onder windows geprobeerd te connecten maar dit lukte ook niet zelfde fout.

"ja ssh draait anders kan ik via ssh naam@localhost niet connecten " -> localhost != 192.168.1.33 lijkt mij? Ah je bedoelt dat je vanuit je VM naar localhost kan connecten.

ssh username@192.168.1.33 werkt ook niet?

Doe een poortscan met nmap op je hele netwerk:
nmap -v -A 192.168.1.*

Als ik met een poortscanner op windows kijk zie ik de poort van ssh maar kan niet connecten.

[Verwijderd]

Dan moet je openssh-server opnieuw installeren lijkt mij (weet je zeker dat er geen extra firewall tussen zit?)

apt-get remove --purge openssh-server
apt-get install openssh-server

[we_are_borg]

Verwijderd schreef op zaterdag 08 augustus 2009 @ 21:47:
Dan moet je openssh-server opnieuw installeren lijkt mij (weet je zeker dat er geen extra firewall tussen zit?)

apt-get remove --purge openssh-server
apt-get install openssh-server

Geen extra Firewall gevonden niet op Linux en ook niet onder windows.

[blaataaps]

Wat is "zie ik de poort van ssh maar kan niet connecten"?

[cherwin]

Een paar zaken zijn mij niet duidelijk:
- Vanaf welke machine probeer je nu verbinding te maken?
- Wat voor netwerkinstellingen heb je ingesteld in vmware?
- Wat zijn de netwerkinstellingen van de relevante machines (e.g. firewall, ip etc.)?
- Heb je aanpassingen gemaakt in sshd_config en wat zijn die?

Wat er nu gebeurd is dat er geen connectie op poort 22 van 192.168.1.113 wordt geaccepteerd. Het is giswerk om de oorzaak te achterhalen, wat meer informatie is gewenst.

we_are_borg schreef op zaterdag 08 augustus 2009 @ 21:14:
[...]


Ja heb ik gedaan (zowel iptables als ~/.shh) ook onder windows geprobeerd te connecten maar dit lukte ook niet zelfde fout.


[...]


Als ik met een poortscanner op windows kijk zie ik de poort van ssh maar kan niet connecten.

Kan je dit wat meer nuanceren, probeer zo duidelijk mogelijk uit te leggen wat je probeert te doen.

Verwijderd schreef op zaterdag 08 augustus 2009 @ 21:47:
Dan moet je openssh-server opnieuw installeren lijkt mij (weet je zeker dat er geen extra firewall tussen zit?)

apt-get remove --purge openssh-server
apt-get install openssh-server

Dit werkt alleen als zijn binary op de een of andere manier niet werkt, óf als hij zijn configuratie bestanden heeft vernaggelt, ik zie nergens dat hij heeft lopen zieken in zijn configuratiebestanden en er wordt er ook niet naar gevraagd of hij daadwerkelijk heeft lopen zieken in die bestanden. Zo los je geen problemen op, door allerlei commando's uit te voeren en hopen dat het werkt. Zorg ervoor dat je snapt wat er gebeurd, de oplossing presenteert zich dan vanzelf.

[we_are_borg]

code:

ssh naam@localhost

Dit werkt in één keer en ik kan het systeem besturen. Nu probeer ik het volgende:

code:

ssh -v naam@192.168.1.113

Ik krijg nu te zien ssh: connect to host 192.168.1.113 port 22: Connection refused

Het bovenstaande voer ik uit op de Linux systeem waarop de client en de server draaien. Is één systeem die onder vmware draait.
Probeer ik te contact te maken vanaf mijn windows systeem dan krijg ik "Disconnected... [Cause: The requested connection has been refused by the remote host.]"
Ik probeer contact te maken via ip adres 192.168.1.113 (dit is de server waarop ssh draait).

Ik heb een herinstallatie gedaan van openssh-server zodat ik weer verse configuratie bestanden heb, helaas mocht dit niet baten.

Ik vind het vreemd dat ik wel connectie kan krijgen als ik localhost doet maar niet als ik het ip adress gebruikt.

[cherwin]

Vandaar dat je even antwoord moet geven op de vragen die ik je net heb gesteld, dan kunnen we o.a. zien of je wel verbinding maakt met het juiste ip. Help ons om jou te helpen

[ Voor 78% gewijzigd door cherwin op 09-08-2009 12:52 ]

[Verwijderd]

Als ik met een poortscanner op windows kijk zie ik de poort van ssh maar kan niet connecten.

Betekend dit dat de poort gefilterd is of openstaat?
Misschien een overbodige vraag, maar heb je wel RSA keys gegenereerd?

Het is logisch dat je via localhost wel kan connecten omdat het geen fysieke verbinding is.

[cherwin]

Verwijderd schreef op zaterdag 08 augustus 2009 @ 23:21:
[...]


Betekend dit dat de poort gefilterd is of openstaat?
Misschien een overbodige vraag, maar heb je wel RSA keys gegenereerd?

Het is logisch dat je via localhost wel kan connecten omdat het geen fysieke verbinding is.

Dit antwoord getuigt ervan dat je niet goed bekend bent met ssh, neem hier eens een kijkje http://www.eng.cam.ac.uk/help/jpmg/ssh/ssh-detail.html

[we_are_borg]

cherwin schreef op zaterdag 08 augustus 2009 @ 22:20:
Een paar zaken zijn mij niet duidelijk:
- Vanaf welke machine probeer je nu verbinding te maken?

Ik probeer vanaf de Linux server contact te maken en vanaf een Windows machine. Windows heeft het IP adres 192.168.1.102 en zit in de zelfde subnet.
Met ssh naam@localhost connect ik in één keer met de sshd nadat ik het wachtwoord ingeeft. Doe ik naam@192.168.1.113 dan mislukt de verbinding binnen een paar seconden.

- Wat voor netwerkinstellingen heb je ingesteld in vmware?

Netwerk instelling die ik gebruik is NAT: Used to share the host's IP Address.

- Wat zijn de netwerkinstellingen van de relevante machines (e.g. firewall, ip etc.)?

Op de Linux machine gebruik ik 192.168.1.113/255.255.255.0 subnet:192.168.1.1 nameserver: 192.168.1.1. Geen firewall geactiveerd op de netwerkkaart, ook niet op de VMware netwerk. Onder Linux heb ik niet een Firewall geïnstalleerd staan zover ben ik nog niet gekomen.
Windows 192.168.1.102/255.255.255.0 subnet: 192.168.1.1 nameserver 192.168.1.1
Firewall staat ook hier uit.

- Heb je aanpassingen gemaakt in sshd_config en wat zijn die?

Nee ik heb een volledige purge gedaan met apt-get remove --purge openssh-server. De aanpassingen die ik gedaan heb hier in zijn nu weg.
In /etc/hosts.allow heb ik sshd : ALL staan. In de deny staat niets.

Wat er nu gebeurd is dat er geen connectie op poort 22 van 192.168.1.113 wordt geaccepteerd. Het is giswerk om de oorzaak te achterhalen, wat meer informatie is gewenst.

Hierbij meer informatie.

[...]
Kan je dit wat meer nuanceren, probeer zo duidelijk mogelijk uit te leggen wat je probeert te doen.
[...]

Dit werkt alleen als zijn binary op de een of andere manier niet werkt, óf als hij zijn configuratie bestanden heeft vernaggelt, ik zie nergens dat hij heeft lopen zieken in zijn configuratiebestanden en er wordt er ook niet naar gevraagd of hij daadwerkelijk heeft lopen zieken in die bestanden. Zo los je geen problemen op, door allerlei commando's uit te voeren en hopen dat het werkt. Zorg ervoor dat je snapt wat er gebeurd, de oplossing presenteert zich dan vanzelf.

Ik ben het met je eens dat ik wat over het hoofd ziet het vreemde is dat ik eerst dacht dat ik een installatie fout maakte dus heb ik vandaag een nieuwe install gedaan. Maar nu blijkt dat ik weer de zelfde fout heb als gisteren. Alles wat ik tot nu heb geschreven is dus van de nieuwe installatie, ik ga er even vanuit dat ik wat over het hoofd ziet.

Ik gebruik de volgende file om debian te installeren debian-502-i386-netinst.iso

[Verwijderd]

cherwin schreef op zaterdag 08 augustus 2009 @ 23:24:
[...]

Dit antwoord getuigt ervan dat je niet goed bekend bent met ssh, neem hier eens een kijkje http://www.eng.cam.ac.uk/help/jpmg/ssh/ssh-detail.html

Oke, ik zal morgen even de tijd nemen.
Waar doelde je precies op dat ik nog niet bekend ben met ssh? (je hebt wel gelijk hoor).
Maar dan weet waar ik fout zat.

Ik gebruik ssh ook alleen om wat files te transferen en remote in te loggen, en heb me inderdaad nooit echt in de stof verdiept.

[ Voor 13% gewijzigd door Verwijderd op 09-08-2009 01:14 ]

[we_are_borg]

Ik heb vannacht een nieuwe installatie gedaan en daarbij gezien dat het een installatie fout betreft. Ik installeer debian via een netwerk install nu kom je op een gegeven moment uit bij welke functie je het systeem wil aanmeten hier zijn een paar opties mogelijk zie plaatje
ik heb hier helemaal niets gekozen ik heb alles uit gezet. In de nieuwe install heb ik standard system aangevinkt en deze werkt wel 100%.

Maar nu waarom gaat de oude install fout met ssh ik doe het via apt-get ik mag er toch vanuit gaan dat apt-get alle relevante pakketten installeer, maar dit wordt dus niet gedaan.

[ Voor 10% gewijzigd door we_are_borg op 09-08-2009 09:51 ]

[blaataaps]

Heb je hier ook weer de "NAT"-optie van vmware networking gekozen?

[cherwin]

Probeer eens bridge mode te gebruiken in vmware, dan zou het moeten werken. Het probleem zit duidelijk in het netwerk, niet in jouw Debian install. Bridge mode zorgt ervoor dat jouw vmware guest fysiek in het netwerk komt te zitten .. stel dus een ip in en probeer dan te verbinden.

Verwijderd schreef op zondditag 09 augustus 2009 @ 01:08:
[...]


Oke, ik zal morgen even de tijd nemen.
Waar doelde je precies op dat ik nog niet bekend ben met ssh? (je hebt wel gelijk hoor).
Maar dan weet waar ik fout zat.

Ik gebruik ssh ook alleen om wat files te transferen en remote in te loggen, en heb me inderdaad nooit echt in de stof verdiept.

Je zei:

Verwijderd schreef op zaterdag 08 augustus 2009 @ 23:21:
[...]
Misschien een overbodige vraag, maar heb je wel RSA keys gegenereerd?

Nou hij heeft de ssh server getest door op de machine te verbinden met localhost en dat werkt. Als je voor het eerst met een ssh server verbinding maakt, zal de server zijn public key sturen en zal je client vragen of je de fingerprint van de key accepteert.

$ ssh ssh-server.example.com
The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

Als je vervolgens de fingerprint van de key accepteert, zal de key toegevoegd worden aan known_hosts en mag je verbinding maken, als je het niet accepteert dan zal je standaard geen verbinding mogen maken. Daarbij komt ook nog het feit dat zijn ssh server niet eens een SYN ziet, daar hij NAT heeft aan staan, waardoor de vmware gast effectief is afgesloten voor verbindingen die vanaf extern worden geïnitieerd.

Dit zou dus niet mogelijk zijn mocht er geen keys aangemaakt zijn, waardoor jouw vraag inderdaad overbodig is.

Het is logisch dat je via localhost wel kan connecten omdat het geen fysieke verbinding is.

Dit is niet logisch om de reden wat jij opgeeft .. het duidt gewoon aan dat het werkt.

[ Voor 104% gewijzigd door cherwin op 09-08-2009 12:51 ]

[CAPSLOCK2000]

we_are_borg schreef op zondag 09 augustus 2009 @ 09:46:
Maar nu waarom gaat de oude install fout met ssh ik doe het via apt-get ik mag er toch vanuit gaan dat apt-get alle relevante pakketten installeer, maar dit wordt dus niet gedaan.

Ik doe dit minstens eens per maand, en het gaat altijd goed. Wat het ook is, het is zeker geen dependency probleem. Ik begrijp dat het nu werkt en dat we er dus waarschijnlijk nooit achter komen wat er mis is gegaan.
Ik vraag me af of je ook een nieuwe Virtual Machine hebt aangemaakt of dat die precies dezelfde configuratie draait.

Mijn vermoede is namelijk dat het netwerk van de VM niet helemaal lekker zat. Je zegt immers NAT te gebruiken. Die machine zou dan (inderdaad) niet van buiten bereikbaar zijn. Daarvoor moet je eerst porten van de host forwarden naar de guest.
De IP adressen die je gebruikt maken het voor mij niet duidelijker. Het suggereert dat je zowel in het fysieke als in het virtuele netwerk adressen uit de 192.168.1.0/24 range gebruikt, wat niet kan in een NAT configuratie (en wel in bridge mode).

[Verwijderd]

Het probleem bij alle ssh problemen zit tussen het beeldscherm en de stoel

[WHiZZi]

Ben ik nou alleen samen met blaataaps dat ik VMWare vermoed . VMware icm NAT gaat gewoon fout.

Bij de eerste reactie is het vermoeden van mij al vmware. Ik vermoed dat hij vmware via NAT heeft geprobeerd wat dus niet werkt om daarna een nieuwe omgeving te bouwen zonder NAT wat wel goed gaat.

Zo jammer dat dit (waarschijnlijk) wordt afgeschoven op "Zie je wel, Debian/Linux is alleen maar vervelend" terwijl het hoogstwaarschijnlijk fout zit in VMWare

[CAPSLOCK2000]

Ik ben het me je eens. VMware + NAT kan prima, maar je moet het wel goed configureren. Bridging is meestal de beter oplossing.

[we_are_borg]

Ik weet niet wat het geweest is ik heb de zelfde instellingen geprobeerd als de eerste VMware in de tweede installatie en die werkte gewoon 100%. Dit draaide eerst op een vmware workstation installatie ik ben nu over gestapt naar de vmware server en die werk ook gewoon goed.

[cherwin]

WHiZZi schreef op dinsdag 11 augustus 2009 @ 16:17:
Ben ik nou alleen samen met blaataaps dat ik VMWare vermoed . VMware icm NAT gaat gewoon fout.
[..]

Je ziet iemand over het hoofd

cherwin schreef op zondag 09 augustus 2009 @ 12:04:
Probeer eens bridge mode te gebruiken in vmware, dan zou het moeten werken. Het probleem zit duidelijk in het netwerk, niet in jouw Debian install.
[...]

[WHiZZi]

ah, sorry cherwin

[Olaf van der Spek]

WHiZZi schreef op dinsdag 11 augustus 2009 @ 16:17:
Ben ik nou alleen samen met blaataaps dat ik VMWare vermoed . VMware icm NAT gaat gewoon fout.

Ja.
Het is van en naar hetzelfde systeem. Als NAT fout loopt, zou ik eerder een time out verwachten.

[lamko]

Waarom wordt er eerst niet gewoon even een simpele ping gedaan daarna even mooi met nmap kijken of de poort ook werkelijk open staat en je weet alle antwoorden.
Tering wat wordt hier moeilijk gedaan!

[r0b]

lamko schreef op woensdag 12 augustus 2009 @ 19:40:
Waarom wordt er eerst niet gewoon even een simpele ping gedaan daarna even mooi met nmap kijken of de poort ook werkelijk open staat en je weet alle antwoorden.
Potjanfluitjes wat wordt hier moeilijk gedaan!

..en een "iptables -L" + "cat /etc/ssh/sshd_config | grep Port" en grep Listen

[c-nan]

lamko schreef op woensdag 12 augustus 2009 @ 19:40:
Waarom wordt er eerst niet gewoon even een simpele ping gedaan daarna even mooi met nmap kijken of de poort ook werkelijk open staat en je weet alle antwoorden.
Tering wat wordt hier moeilijk gedaan!

Inderdaad, ik was aan het lezen en ik niemand die even kijkt of de netwerk instellingen wel in orde zijn d.m.v. ping

[cherwin]

Olaf van der Spek schreef op woensdag 12 augustus 2009 @ 14:47:
[...]

Ja.
Het is van en naar hetzelfde systeem. Als NAT fout loopt, zou ik eerder een time out verwachten.

lamko schreef op woensdag 12 augustus 2009 @ 19:40:
Waarom wordt er eerst niet gewoon even een simpele ping gedaan daarna even mooi met nmap kijken of de poort ook werkelijk open staat en je weet alle antwoorden.
Tering wat wordt hier moeilijk gedaan!

r0b schreef op woensdag 12 augustus 2009 @ 20:06:
[...]

..en een "iptables -L" + "cat /etc/ssh/sshd_config | grep Port" en grep Listen

Polat06 schreef op vrijdag 14 augustus 2009 @ 02:17:
[...]


Inderdaad, ik was aan het lezen en ik niemand die even kijkt of de netwerk instellingen wel in orde zijn d.m.v. ping

En als je nou niet weet *wat* je moet pingen? Jullie gaan er van uit dat het ip wat hij opgeeft ook daadwerkelijk het juiste ip is. Wat nou als het ip wat hij pingt gewoon van zijn machine is en niet van de virtuele machine? Dan krijg je wel een mooie echo-reply en dan werkt het nog steeds niet, daar het niet de goeie machine is

Een wijs advies dat ik heb gekregen en wat jullie allemaal in het achterhoofd moeten houden; "Assumption is mother of all fuckups!"

Verder, als je wilt dat een virtuele machine van buitenaf bereikbaar is, zul je toch eerst wat instellingen moeten aanpassen. Dus ping is gewoon overbodig op dit moment, je pingt toch ook geen machine zonder netwerkinstellingen onder het mom "even kijken of het al werkt", je stelt het eerst goed in alvorens je gaat pingen. Dat geldt ook voor NAT die je wilt bereiken van host -> guest. VMWare speelt in dit geval een nat routertje na en zal alles wat niet established en/of related is niet door laten (tenzij je met forwarding aan de slag gaat).

[ Voor 21% gewijzigd door cherwin op 14-08-2009 21:31 ]

[lamko]

Sorry maar als we daar niet vanuit mogen gaan is het niveau hier echt diep gezonken.
Hij weet wat ssh is is en dus dan mag je ook wel wat meer verwachten. We zijn hier niet een forum zoals helpmij.nl. Sommige dingen zul je ook nooit op een forum oplossen omdat bepaalde dingen op dat moment niet opvallen. Een forum zie ik als een handreiking niets meer niets minder een zetje in de goede richting.

[Dafjedavid]

WHiZZi schreef op dinsdag 11 augustus 2009 @ 16:17:
Ben ik nou alleen samen met blaataaps dat ik VMWare vermoed . VMware icm NAT gaat gewoon fout.

Bij de eerste reactie is het vermoeden van mij al vmware. Ik vermoed dat hij vmware via NAT heeft geprobeerd wat dus niet werkt om daarna een nieuwe omgeving te bouwen zonder NAT wat wel goed gaat.

Zo jammer dat dit (waarschijnlijk) wordt afgeschoven op "Zie je wel, Debian/Linux is alleen maar vervelend" terwijl het hoogstwaarschijnlijk fout zit in VMWare

Misschien ligt t aan geen van beide, maar aan betreffende gebruiker.
Als zijn vmware NAT een adres uitgeeft van 192.168.1.x en zijn thuisnetwerk doet dat ook, dan kun je daar ook een ip-conflict/netwerk conflict in krijgen....

Het zal m inderdaad wel in de netwerkinstellingen liggen.... Gebruik dus inderdaad bridged. Dan gaat t zeker goed.

Heb ervaring genoeg met VMWare en de NAT functie werkt bij mij wel altijd.... Dus dat het aan de NAT van VMware zou liggen en dat dit nooit zou werken is ook niet waar. Dat het aan de netwerkinstellingen ligt geloof ik direct!