porte logiche

[Filippo_one_web]

ancora qua,e visto che l altra mia domanda non ha trovato risposta,sto cerdcando do risolvere un altro problema,che secondo me è collegato all'altro...comunque,io provo ad entrare sul mio pc da remoto,tramite telnet,ssh,ma tutte le connessioni mi vengono rifiutate,tranne quella sulla porta 110!!!cioè io scrivo
telnet linux.trepuntoom.it 110
e lui mi attiva una connessione,mentre su un altra porta mi blocca e comunque non mi fa accedere in generale.Cosa vuol dire?Il firewall non è installato,quindi non penso sia quello che mi blocchi,da cosa può dipendere secondo voi?sareste così gentili da darmi una spiegazione?grazie

[robydrupo]

ma i servizi telnet e ssh sono attivi?

[Filippo_one_web]

si,ma ora nn mi fa più connettere in nessun modo

[Filippo_one_web]

anzi tramite ssh nomehost mi fa connettere

[Filippo_one_web]

il tutto è partito dal fatto che utilizzando kmail,quando invio mi dice che è impossibile stabilire una connessione con il server(che è sempre sulla mia macchina)

[robydrupo]

se non sbaglio ci sono due file hosts.allow e hosts.deny per ssh che bloccano o abilitano l'accesso ad indirizzi IP specifici...prova a darci un'occhiata.

[Filippo_one_web]

vado

[Filippo_one_web]

questo è quello che c'è in allow
/etc/hosts.allow
# See `man tcpdŽ and `man 5 hosts_accessŽ for a detailed description
# of /etc/hosts.allow and /etc/hosts.deny.
#
# short overview about daemons and servers that are built with
# tcp_wrappers support:
#
# package name | daemon path | token
# ----------------------------------------------------------------------------
# ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port>
# quota | /usr/sbin/rpc.rquotad | rquotad
# tftpd | /usr/sbin/in.tftpd | in.tftpd
# portmap | /sbin/portmap | portmap
# The portmapper does not verify against hostnames
# to prevent hangs. It only checks non-local addresses.
#
# (kernel nfs server)
# nfs-utils | /usr/sbin/rpc.mountd | mountd
# nfs-utils | /sbin/rpc.statd | statd
#
# (unfsd, userspace nfs server)
# nfs-server | /usr/sbin/rpc.mountd | rpc.mountd
# nfs-server | /usr/sbin/rpc.ugidd | rpc.ugidd
#
# (printing services)
# lprng | /usr/sbin/lpd | lpd
# cups | /usr/sbin/cupsd | cupsd
# The cupsd server daemon reports to the cups
# error logs, not to the syslog(3) facility.
#
# (Uniterrupted Power Supply Software)
# apcupsd | /sbin/apcupsd | apcupsd
# apcupsd | /sbin/apcnisd | apcnisd
#
# All of the other network servers such as samba, apache or X, have their own
# access control scheme that should be used instead.
#
# In addition to the services above, the services that are started on request
# by inetd or xinetd use tcpd to "wrap" the network connection. tcpd uses
# the last component of the server pathname as a token to match a service in
# /etc/hosts.{allow,deny}. See the file /etc/inetd.conf for the token names.
# The following examples work when uncommented:
#
#
# Example 1: Fire up a mail to the admin if a connection to the printer daemon
# has been made from host foo.bar.com, but simply deny all others:
# lpd : foo.bar.com : spawn /bin/echo "%h printer access" | \
# mail -s "tcp_wrappers on %H" root
#
#
# Example 2: grant access from local net, reject with message from elsewhere.
# in.telnetd : ALL EXCEPT LOCAL : ALLOW
# in.telnetd : ALL : \
# twist /bin/echo -e "\n\raccess from %h declined.\n\rGo away.";sleep 2
#
#
# Example 3: run a different instance of rsyncd if the connection comes
# from network 172.20.0.0/24, but regular for others:
# rsyncd : 172.20.0.0/255.255.255.0 : twist /usr/local/sbin/my_rsyncd-script
# rsyncd : ALL : ALLOW
#
spop3: ALL
simap: ALL

QUESTO IN DENY

# /etc/hosts.deny
# See `man tcpdŽ and `man 5 hosts_accessŽ as well as /etc/hosts.allow
# for a detailed description.

http-rman : ALL EXCEPT LOCAL

[best1980]

Mi sembra una cosa molto strana... se hai i servizi veramente attivi, (e questo lo puoi verificare lanciando dal server netstat -nat e controllando quali sono le porte in LISTENING) facendo un 'telnet nome_pc porta' dovrebbe per forza risponderti qualcosa... se così non è penso sia dovuto al fatto che sulla macchina server o client è installato un firewall che blocca le connessioni... se sul server dici che non è installato un fw controlla se è installato sul client...

[best1980]

l'hosts.allow e .deny se non mi sbaglio sono file di configurazione del tcp wrapper e questo è usato solo nel file inetd.conf. Quindi non penso centri con il demone di ssh che è lanciato in stand-alone e non tramite il superdemone inetd.

Ssh quindi dovrebbe essere indipendente da questi file e quindi tramite il comando telnet nome_pc 22 dovresti avere una risposta...