petit up, Il n'y a t-il vraiment aucune solution?
sur 3 pc ca fait beaucoup quand meme.
salut, Merci de passer du temps a chercher une solution.
Je pense que cette histoire de carte reseau ne tiens pas la route j'explique plus bas en attendant voici ce que tu a demande.
PC1 n'est pas en DHCP l'adresse est rentrer manuellement les autres sont en DHCP sur routeur TPlink.
ma machine du bureau donc PC4 se connecte a nos serveurs mais refuse que je me connecte a moi meme via ssh iplocal. et quand je l'emmene a la maison elle ne se connecte plus a rien.
Donc visiblement le coupable c'est openssh-server de fedora 22 , je dis fedora 22 car 2 des machines marchait avant le passage a fedora superieur. pour le PC de bureau il etait sous debian et il marchait sans probleme depuis que je l'ai mis sous fedora 22 le meme probleme.
bon ssh -v donne:
OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.9
debug1: match: OpenSSH_6.9 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:ztNZa8t+PhxiH60fffpsW4wTpZukIFfkUkMGN4JNAF4
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:17
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@localhost's password: 
debug1: Authentication succeeded (password).
Authenticated to localhost ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
packet_write_wait: Connection to 127.0.0.1: Broken pipe
Tu sembles utiliser une clé ecdsa, le souci pourrait venir de là.
Si tu veux bien, fais des tests avec une clé rsa.
j'utilise des clés ecdsa-sha2-nistp256xxxxxxxxxxxx sans ce problème mais je n'utilise ces clés que pour une "authentification machine" en particulier pour x2go avec la même version d'openssh.
Gérard
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
Ca n'a pas changer grand chose, mise a jour de sshd_conf et redemarrage du service et toujours la meme erreure
j'ai eut une fois un problème qui venait de la configuration du firewall ! pourrais-tu essayer en désactivant le firewall ? je n'y crois pas trop mais c'est ma dernière idée
Gérard
Bonjour,
et si tu fais ???
$ ssh user@192.168.28.44
@fgland
systemctl stop firewalld
rien ne change

@antbel a l'origine je faisais que ca, je me suis dit que peut etre que localhost passait mais en faite non rien ne marche. bon la je vais essayer depuis une machine windows avec putty. j'attend qu'un collegue me passe son laptop sous debian pour voir ce qui coince.
depuis putty j'ai "server inexpected close connection"
j'ai "broken pipe" avec debian vers fedora
mais aucun probleme de fedora vers debian
j'en deduit que soit sshd bloque soit j'ai quelque chose dans les installations qui bloque les connections rentrentes ssh
et coté Selinux ?
Dans les logs secure n'y a-t-il pas d'info sur ces connexions ?
Gérard
alors 
#ausearch -m avc --start today
<no matches>
donc il n'a fait aucun denial.
sinon j'ai fait 
setenforce 0
et ca marche toujours pas.
re-
Ceci sur tous tes linux
Ca change rien. En faite ssh en verbose dit clairement que l'authentification est passe.
ce qui ce passe c'est que la connexion est cassee des qu'elles est etablie.
du nouveau , voici ce que me donne /var/log/secure:
Sep  2 22:37:45 v19ler sshd[17055]: Accepted password for v19l from 127.0.0.1 port 33296 ssh2
Sep  2 22:37:45 v19ler sshd[17055]: fatal: privsep_preauth: preauth child terminated by signal 31
bon en fouillant dans /etc/ssh/sshd_conf j'ai vu cette ligne
UsePrivilegeSeparation sandbox         # Default for new installations.
qui ressemble a privsep_preauth.
je viens de mettre la ligne en commentaire relance sshd et ca marche.
avant de mettre resolut j'aimerai bien savoir ce que je viens de commenter. c'est pas dangereux?
de plus on voit en commentaire que pour les nouvelles installation c'est la config par defaut, pourquoi j'ai l'air d'etre le seul au monde a avoir ce probleme?
Bonsoir, effectivement il y a problème.
Quand tu as dégainé le 27/08, ta version ssh :

OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015

n'a été mise à jour chez moi que le 2 septembre. et effectivement mes connexions sur des raspberry pi avec les versions :

OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013

posent problème.
Ta solution ne marche pas.
Il y a connexion, mais chez moi, le transfert de fichier ou création de répertoire distant ne marchent plus.

Chez le client le fichier /etc/ssh/ssh-config avait la ligne : host * commentée en retirant le #, je peux créer le répertoire distant mais pas envoyer de fichier. La connexion est interrompue

A suivre, je lis la doc et les changelog
je n'ai pas cette ligne dans le fichier /etc/ssh/sshd_conf
Gérard
Moi j'ai aussi:
UsePrivilegeSeparation sandbox # Default for new installations
# rpm -q openssh-server
openssh-server-6.9p1-6.fc22.1.x86_64