Newsgroup: it.comp.os.linux.sys
Titolo: Login via SSH con chiave pubblica che non funziona con IPv6

Ciao a tutti!
Stranissimo problema, stasera...
Ho un vServer appena installato, con Ubuntu 10.04, sul quale ho anche un
IPv6.
Ora, se provo a loggarmi usando l'IPv4 riesco ad usare le chiavi che ho
salvato in authorized_keys2, mentre se uso l'IPv6 picche! Mi chiede sempre
la password.
Qualcuno ha idea di cosa possa essere successo e come rimediare?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ssh -vvv credo ti possa dare più dettagli
Adesso giuro che sto per impazzire...
Se cancello da known_hosts le righe che riguardano quel Server, funziona
tutto.
Faccio logout e tento nuovamente il Login, ecco che mi dice che il Remote
Host Identification e' cambiato.
A questo punto immagino che il problema non sia piu' semplicemente del
Login con IPv6, ma qualcosa di piu' grave sul Server...
Idee su cosa cercare?


 Login con IPv6, ma qualcosa di piu' grave sul Server...
Di male in peggio... Adesso il maledetto mi taglia la connessione, cosi',
senza dire niente:
lucabert@new:~$ debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host MIO.SERVER.TLD: Connection reset by peer
Connection to MIO.SERVER.TLD closed.
debug1: Transferred: stdin 0, stdout 0, stderr 110 bytes in 16.8 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 6.5
debug1: Exit status -1
debug1: compress outgoing: raw data 757, compressed 466, factor 0.62
debug1: compress incoming: raw data 1796, compressed 881, factor 0.49
Ma questo SOLO se mi loggo via IPv6. Via IPv4 funziona tutto...
Chelle'?!?
Ciao
Luca Bertoncello


 Read from remote host MIO.SERVER.TLD: Connection reset by peer
Se fai ping6 in remoto verso ::1 e non ti cade, il problema e' nella
configurazione di sshd (c'e' una variabile sul tempo di inattivita'
della connessione che per l'IPv6 e' settata sempre male)
Jey
-- 
Non prendere la vita troppo sul serio... non ne uscirai mai vivo
http://www.joram.it/servizi/consulente.htm

 della connessione che per l'IPv6 e' settata sempre male)
Cosa intendi con "ping6 in remoto verso ::1"? ::1 non e' remoto...
Ho comunque provato a lanciare un ping6 sul Server e a collegarmici via
SSH.
Dopo qualche secondo SSH cade...
Questa e' la mia configurazione (esattamente identica a quella di tutti
gli altri Server Ubuntu 10.04 che ho installato finora e che funzionano
perfettamente con IPv6):
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind
to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/
issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
Sinceramente comincio a pensare che sia il Provider che ha idee un po'
strane sul traffico IPv6 e che, per motivi oscuri, mi seghi via la
connessione dopo un po'...
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)


 della connessione che per l'IPv6 e' settata sempre male)
Ho comunque anche provato a loggarmi sul Server (via IPv6) e a pingare
::1. Niente da fare. Dopo un po' si chiude.
La stessa cosa se provo a pingare un qualche Host remoto (tipo il mio
Server).
Fantasmini?
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)


 connessione dopo un po'...
Puoi scoprirlo aprendo una trentina di sessioni ssh e contando il tempo
che impiega ed andare giu' la connessione: se il tempo e' sempre lo
stesso, il problema potrebbe essere di un provider che mette dei filtri
IPv6 (tipicamente) per limitare il traffico P2P visto che molti
programmi P2P hanno imparato ad usare IPv6 su IPv4 ben prima di molti
provider proprio per superare alcuni filtri. PEr questo motivo, molti
IDS hanno delle firme apposite per rompere le scatole ad IPv6 ed alcuni
provider non si fanno scrupoli ad attivarle.


 #Locale: ssh -6 ind.ip.host.remoto
Scusa, intendevo
#Locale: ssh -6 ind:ip:host::remoto
(deformazione da IPv4 :-P)


 IPV6 ma funziona con V4?
Se fosse cosi', credo che proprio non porterebbe a buon fine la
connessione.


 connessione.
Oltretutto il mio IPv6 HA un Reverse...
Non vorrei che fosse il provider che fa cose strane...
Ciao


 Oltretutto il mio IPv6 HA un Reverse...
La butto li': non e' che bisogna mettere qualcosa in /etc/hosts.allow?
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.