ssh prob ?

[Verwijderd]

ik heb op mijn server ssh draaien nou wil ik als ik bij iemand anders zit gewoon kunnen inloggen zodat ik een user kan aanmaken ofzo... maar ik kan niet inloggen niet met putty en niet met tera term pro.. ze geven een timout error maar als ik me comp ping heb ik een ping van 10 hoe kan dit ??

[satcp]

Je hebt toch niet toevallig een firewall lopen op de machine waar de SSH deamon op draait die poort 22 blokeert?

En hoe draait SSH? Als standalone (aan te raden) of als (x)inetd?

[Verwijderd]

kan je wel zelf met ssh inloggen lokaal.

doe anders ff een scan op poort 22.

[Verwijderd]

ik kan lokaal wel inloggen op poort 22... dat is juist het vage

[Dromer]

host.allow mischien?
Klink als alleen je lokale netwerk telnet toegang geven.

[Mior]

host.allow en host.deny zijn alleen voor de daemons die door inetd gespawnd worden.

Dit klinkt als een firewall probleem. Heb je een firewall draaien? Zo ja, zet hem eens uit om te kijken of het dan werkt.

[Dromer]

je kan in je host.allow en host.deny dus echt wel je telnet en ssh blokken.

[Verwijderd]

Op vrijdag 01 juni 2001 23:40 schreef Dromer het volgende:
je kan in je host.allow en host.deny dus echt wel je telnet en ssh blokken.

klopt !!!! voor bepaalde host of helemaal

[Verwijderd]

het zit niet in me firewall en host.allow en hosts.deny staan ook goed

[ralfbosz]

Op zaterdag 02 juni 2001 00:04 schreef bagger3001 het volgende:
het zit niet in me firewall en host.allow en hosts.deny staan ook goed

Telnet eens naar poort 22 van je machine, dus gewoon: telnet host 22

dan hoor je iets krijgen van OpenSSH met versie nummer. Of een foutmelding die je wat meer info geeft over het probleem...

[Mior]

Op vrijdag 01 juni 2001 23:40 schreef Dromer het volgende:
je kan in je host.allow en host.deny dus echt wel je telnet en ssh blokken.

Als die door inetd gespawnd worden wel ja.

Zie ook: http://www.linux.com/develop/man/5/hosts.deny/

[Verwijderd]

Op zaterdag 02 juni 2001 00:28 schreef Phantom_ het volgende:

[..]

Als die door inetd gespawnd worden wel ja.

Zie ook: http://www.linux.com/develop/man/5/hosts.deny/

Yep dit klopt helemaal.
Het geld dus inderdaad alleen voor services via de superserver inetd.
Een veel gemaakte fout is denken dat het voor alle daemons geldt.

Maar het probleem is inderdaad waarschijnlijk een firewall probleem als SSH standalone draait.
Als hij via inetd draait dan kan het aan zowel je firewall als aan /etc/hosts.allow /etc/hosts.deny liggen.

[igmar]

Op zaterdag 02 juni 2001 00:28 schreef Phantom_ het volgende:

[..]

Als die door inetd gespawnd worden wel ja.

Zie ook: http://www.linux.com/develop/man/5/hosts.deny/

SSH kan ook met tcp_wrappers lib gecompiled zijn, en dan kijkt ie dus ook naar /etc/hosts.allow / deny.

En ja, ZONDER dat ie door inetd gespawned word.


Igmar

[igmar]

Op zaterdag 02 juni 2001 00:55 schreef nelske het volgende:

[..]

Yep dit klopt helemaal.
Het geld dus inderdaad alleen voor services via de superserver inetd.
Een veel gemaakte fout is denken dat het voor alle daemons geldt.

Maar het probleem is inderdaad waarschijnlijk een firewall probleem als SSH standalone draait.
Als hij via inetd draait dan kan het aan zowel je firewall als aan /etc/hosts.allow /etc/hosts.deny liggen.

Het bovenstaande is complete nonsens. Het gaat erom of de applicate gebruikt maakt van tcp_wrappers, en inetd is er toevallig een van.

OpenSSH neemt ook standaard de tcp_wrappers lib mee, dus ook zonder inetd werkt de hosts.allow / deny file.

Igmar

[Verwijderd]

kan iemand ff naar me telnetten?? op poort 22 als je naar me icq'd dan paas ik je me ip...

[deadinspace]

ik kan je gewoon pingen, maar als ik je portscan, zijn *alle* gescande ports onbereikbaar. (dus niet closed, maar filtered).

Dit lijkt mij typisch voor een te radikaal ingestelde firewall

[Verwijderd]

Misschien Soneraplaza als internetprovider?
Sonera filtert namelijk alle poorten onder de 1000 op inkomend verkeer. Ik heb mijn sshd ook naar een poort boven de 1000 moeten verhuizen.

Als je geen Sonera hebt kun je ook de onderstaande test firewall laden.(Er van uitgaande dat je ipchains gebruikt). Deze firewall zet alle poorten open dus alleen voor testdoeleinden gebruiken!

#!/bin/sh

echo "Enabling IP MASQ, MASQ timeouts, MASQ modules and simple firewalling"

#Load the MASQ modules
#BSDComp/sbin/modprobe bsd_comp
#
echo Loading MASQ modules
#/sbin/modprobe ip_masq_cuseeme
/sbin/modprobe ip_masq_ftp
#/sbin/modprobe ip_masq_irc
#/sbin/modprobe ip_masq_quake
#/sbin/modprobe ip_masq_vdolive

# NOTE: Though Real Audio will work without this module, the data
# will be coming in TCP mode vs. UDP mode. With this
# module, you can enable UDP mode and possibly clean up
# any "glitches" in the sound stream
/sbin/modprobe ip_masq_raudio

# Finished with MASQ modules

# Multicast is a powerful, yet seldom used aspect of TCP/IP for multimedia
# data. Though it isn't used much now (because most ISPs don't enable
# multicast on their networks, it will be very common in a few more
# years. Check out www.mbone.com for more detail.
#
echo "Adding multicast route.."
/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

echo "Enabling IP Masqurading.."
echo "1" > /proc/sys/net/ipv4/ip_forward

#Note: Redhat users can enable this also by turning the
# flag forward flag on in /etc/sysconfig/network
#
# Change the forward line to
# FORWARD_IPV4=true

#2.2.x+ kernels with IPCHAINS # Multicast is a powerful, yet seldom used aspect of TCP/IP for multimedia
# data. Though it isn't used much now (because most ISPs don't enable
# multicast on their networks, it will be very common in a few more
# years. Check out www.mbone.com for more detail.
#
# NOTE: Adding this feature is OPTIONAL
#
echo "Adding multicast route.."
/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

echo "Enabling IP Masqurading.."
echo "1" > /proc/sys/net/ipv4/ip_forward

#Note: Redhat users can enable this also by turning the
# flag forward flag on in /etc/sysconfig/network
#
# Change the forward line to
# FORWARD_IPV4=true

#2.2.x+ kernels with IPCHAINS ONLY
#
echo " - Setting Policies: IN/OUT is ACCEPT; FWD is reject (poor security; great functionality)"
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward REJECT

echo " - Flushing any old rule sets"
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward

echo "Extending MASQ timeouts.."
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (Important for MASQ'ed ICQ users)
#
# IPCHAINS
/sbin/ipchains -M -S 7200 10 60

echo "Enable IP Masq.."
#
#IPCHAINS
ipchains -A forward -s 192.168.1.0/24 -j MASQ

echo "rc.firewall done."
ONLY

[Verwijderd]

Op zaterdag 02 juni 2001 11:20 schreef igmar het volgende:

[..]

Het bovenstaande is complete nonsens. Het gaat erom of de applicate gebruikt maakt van tcp_wrappers, en inetd is er toevallig een van.

OpenSSH neemt ook standaard de tcp_wrappers lib mee, dus ook zonder inetd werkt de hosts.allow / deny file.

Igmar

LOL een beetje voor onzin uitgaan maken
Zal ik dan jouw post ook maar even voor onzin uitmaken? Dat is namelijk nog grotere onzin dan mijn foutje, dat er inderdaad wel is.

Euhm er zat inderdaad een klein foutje in en dat is het vermelden van tcpwrappers.
Via inetd kun je inderdaad ervoor zorgen dat een daemon via een tcpwrappers draait (tcpd).

De fout dat ik zei dat het alleen voor daemons geldt die via inetd draaien klopt, dit moet dus inderdaad de daemons zijn die via een tcpwrapper draaien.

Waar jij de fout maakt, is dat ten eerste OpenSSH niet standaard met tcpwrapper support compileert, maar dat dat expliciet opgegeven moet worden!!!!
(tenminste niet de laatste keren dat ik OpenSSH installeerde)

Verder heeft OpenSSH nog altijd wel de headers van de tcpwrapper (tcpd in dit geval) nodig om te kunnen compileren, indien je dus tcpwrapper support wil.