Bonjour à tous,

désolé pour la longue absence mais déménagement/changement de boulot ont pris du temps pour émerger !

Donc je reviens avec un bug que je ne comprends pas et pour lequel je pensais qu'en passant à F14 tout allait être résolu.

Machine à laquelle je me connecte :
Je tente de me connecter à une serveur distant qui n'utilise pas un port standard avec la commande ssh -p xxx login@ip mais aussi c'est une connexion sans mot de passe (clefs rsa).

Machine avec laquelle je me connecte :
Si je me connecte depuis l'ordinateur portable sous Fedora 14 (et F13 avant) avec cette commande tout fonctionne parfaitement.

Machine avec laquelle ça ne connecte pas :
Par contre, si je me connecte depuis le pc fixe sous F14 (et avant F13) avec la même clef, la même commande j'ai :
ssh -p xxx login@ip -vvv
OpenSSH_5.5p1, OpenSSL 1.0.0a-fips 1 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to ip [ip] port xxx.
debug1: connect to address ip port xxx: Connection timed out
ssh: connect to host ip port xxx: Connection timed out
Pour information :
# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:1B:FC:C1:C3:EE  
          inet addr:192.168.0.11  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::21b:fcff:fec1:c3ee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10137649 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7947872 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10720294169 (9.9 GiB)  TX bytes:4627716175 (4.3 GiB)
          Interrupt:16 Base address:0x8c00 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:527 errors:0 dropped:0 overruns:0 frame:0
          TX packets:527 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:46019 (44.9 KiB)  TX bytes:46019 (44.9 KiB)
Tests et informations supplémentaires :
Les deux machines sont reliées en éthernet sur un routeur netgear numéricable. Pour le pare-feu, j'ai essayé de mettre le pc fixe en dmz et de voir si ça fonctionne mais non...
J'ai comparé les fichiers locaux /etc/ssh/ssh_config : identiques
J'ai vérifié que les clefs sont identiques : toujours pas...
J'ai joué avec selinux en permissif, disabled, enforcing, ajouté des règles pour autoriser du ssh : toujours rien.
Depuis le serveur distant mon ordinateur n'est pas bloqué (sinon le portable passerait pas vu que c'est la même ip). D'ailleurs j'ai essayé en désactivant le pare-feu sur la machine distante (quitte à tout essayer).
Sur le fixe j'ai essayé de désactiver le pare-feu et de mettre les même règles que sur le portable : toujours pareil.
Quand je regarde les logs sur la machine distante et sur la machine locale aucun fichier n'est modifié.

Si quelqu'un a une idée ou a déjà eu ce problème ?

Merci !
bonjour,

je ne sais pas si mon aide va être très utile, mais voici ci-dessous la procédure que j'utilise pour générer mes clefs ; un des points clefs est de bien faire attention aux permissions

sur le PC client et sous le compte user
[user@client_ssh]$ ssh-keygen -b 4096 -t rsa -f id_rsa

[user@client_ssh]$ cp id_rsa ~/.ssh/
[user@client_ssh]$ chmod 600 ~/.ssh/id_rsa

[user@client_ssh]$ cp id_rsa.pub ~/.ssh/
[user@client_ssh]$ chmod 644 ~/.ssh/id_rsa.pub

[user@client_ssh]$ ssh-copy-id -i id_rsa.pub user@serveur_ssh

si, pour diverses raisons, le ssh-copy-id n'est pas facilement réalisable au travers du réseau, alors
sur le PC serveur, sous le même compte user
[user@serveur_ssh]$ cat client_id_rsa.pub >> ~/.ssh/authorized_keys
[user@serveur_ssh]$ chmod 644  ~/.ssh/authorized_keys
[user@serveur_ssh]$ chmod 700 ~/.ssh
la dernière étape consiste à configurer le fichier /etc/ssh/sshd_config ; voici le mien :
#    $OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

LoginGraceTime 30
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 3

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile    .ssh/authorized_keys
#PubkeyAgent none
#PubkeyAgentRunAs nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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 no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
Compression yes
ClientAliveInterval 15
ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
MaxStartups 3:50:10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    ForceCommand cvs server

AllowUsers biloute
#ListenAddress 192.168.1.2
c'était ma config qui marchait bien sous F13, pas encore testée sous F14, mais ça ne saurait tarder
Bonjour,

merci pour la réponse.

En fait je n'ai pas à refaire les clefs vu qu'elles sont déjà créés et fonctionnelles sur l'ordinateur portable donc sur le fixe aussi je suppose (déjà testé aussi pour un putty sous Windows).

Du côté serveur je vois pas pourquoi je changerai ma configuration qui fonctionne sur le portable, un ordinateur Windows et plusieurs autres machines avec des users différents.
De plus la configuration proposée ne passe pas par un port spécifique.
essaie de changer l'adresse MAC de la carte réseau du "PC à problème" pour voir si ça change quelque chose (quoique s'il est planqué derrière un routeur, ça risque de ne pas changer grand chose ...)
# macchanger -A eth0
Bonjour,
depuis le PC qui pose pb, essaye de faire : telnet LESERVEUR LEPORT puis regarde si tu obtiens le prompt SSH-2.0-OpenSSH_4.3
MarbolanGos wrote:[...]De plus la configuration proposée ne passe pas par un port spécifique.
pour le changement de port, plusieurs solutions :
  • tu peux changer le port par défaut dans /etc/ssh/sshd_config, par exemple :
    Port 2222
    et ensuite autoriser le trafic sur ce port :
    iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 2222 -i eth0 -m state --state ESTABLISHED,NEW -j ACCEPT
    iptables -t filter -A OUTPUT -p tcp --sport 2222 --dport 1024:65535 -o eth0 -m state --state ESTABLISHED -j ACCEPT
  • tu peux aussi rediriger le port en entrée à l'aide d'iptables, par exemple le port 80 vers le port 2222 :
    iptables -t nat -A PREROUTING -p tcp --sport 1024:65535 --dport 80 -i eth0 -j REDIRECT --to-port 2222
mais ton problème se situe sans doute ailleurs
proxy wrote:Bonjour,
depuis le PC qui pose pb, essaye de faire : telnet LESERVEUR LEPORT puis regarde si tu obtiens le prompt SSH-2.0-OpenSSH_4.3
$ telnet ip XXX
Trying ip...
telnet: connect to address ip: Connection timed out
Donc c'est bien ce que je comprends il n'arrive pas à comprendre par où passer ou un truc du style parce que sur le portable ça fonctionne...
Le soucis vient de cet ordinateur mais je pige pas où est la différence !

Au passage depuis l'ordinateur fixe je ping l'ip avec 35ms de réponse donc ça n'est pas cohérent avec un timeout...

J'ai essayé de réinstaller le openssh (en plus y'a eu une MAJ récemment).

@lmaurin: yep tout à fait pour la config du sshd. Mes règles iptables je pense qu'elles fonctionnent bien puisque ça marche depuis d'autres machines...
Donc ce n'est pas un pb ssh mais un pb de route.
Compare le résultat de la commande traceroute LESERVER depuis les 2 PCs
Pour le portable :
 1  * * *
 2  * * *
 3  * * *
 4  * ... (80.236.7.201) 11.354ms *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
Pour le fixe :
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  rbx-2-6k.fr.eu (213.186.32.201)  136.156 ms * *
 6  rbx-52-m1.fr.eu (91.121.130.156)  148.494 ms  45.362 ms  44.294 ms
 7  * * *
 8  * * *
 9  * * *
Du coup j'ai revérifié le fichier /etc/hosts (environ identique : la seule différence fedoraport ou fedora comme nom...)
J'ai revérifié que j'avais le même dns 89.2.0.1 et 89.2.0.2
Pas de hosts.deny ou de hosts.allow

Dans NetworkManager j'ai supprimé le profil utilisé pour se connecter et je l'ai refait (il est en DHCP de toute façon donc pas dur à refaire)...

Je pense que je vais tenter l'autre prise ethernet de la machine pour voir...
Tu as 2 prises ?
Sont elles actives ttes les 2 ?
Que renvoie la commande : route
En fait j'ai deux cartes réseaux sur la carte mère mais j'avais désactivé la deuxième dans le bios vu qu'elle me servait à rien.

J'ai donc fait l'inverse et là ça fonctionne. Problème résolu : une des cartes réseau était HS !
Un peu dégouté parce que pour tout le reste ça fonctionnait bien.

Merci pour l'aide !