des troubles sshd Résolu

Question

Bonjour,

des fois quand j'essaye d'arreté  le service sshd j'ai ce message  : sshd failed. The error was: Arrêt de sshd :[ÉCHOUÉ] .
je suis sous fedora , alors j'ai  fais la commande suivante pour savoir quel sont les processus qui tourne  

#ps -ef 
root      3110     1  0 10:08 ?          00:00:00 /usr/sbin/sshd
root      3130  3110  0 10:09 ?         00:00:00 sshd: zen [priv]
zen      3133  3130  0 10:09 ?        00:00:00 sshd: zen@pts/2

et chez un copain avec la meme configuration il a 2 lignes seulements  


root      7216     1  0 Aug29 ?        00:00:03 /usr/sbin/sshd

root     30809  7216  0 08:51 ?        00:00:00 sshd: fber@pts/2

et j'ai meme des fois connection refused pas toujours 
alors merci de vos indications 
merci

[Dal] · Answer

Salut,

A mon sens, il n'y a rien de bizarre dans ta commande ps (on y voit le processus du serveur sshd et ceux des connexions clientes).

Il semble fonctionner.

des fois quand j'essaye d'arreté le service sshd j'ai ce message : sshd failed. The error was: Arrêt de sshd :[ÉCHOUÉ] . 

Comment essayes-tu d'arrêter sshd ?

Fais-tu :

service sshd stop

?

En tant que root, comme tu es sensé le faire sous Fedora (https://www.fedorafaq.org/basics/#services)


Dal

cazersose · Answer

oui , c'est cette commande que j'utilse

cazersose · Answer

j'ai une question c'est quoi ce processus privé :
root 3130 3110 0 10:09 ? 00:00:00 sshd: zen [priv]

[Dal] · Answer

C'est un processus de sshd pour l'utilisateur connecté au serveur dont le nom unix est "zen"


Dal

cazersose · Answer

et le truc entre []  c'est quoi   ???  c'est pas la meme chose chez mon copain

[Dal] · Answer

Salut,

Dans cette colonne figurent les commandes rapportées par "ps", avec leurs options éventuelles. Là, ce sont probablement les options données par sshd à lui même pour générer le "fork" de lui-même qui gère une connexion cliente.

Ce que je peux te dire, c'est que cela n'est pas anormal. Si tu veux connaitre la signification profonde, peut-être pourrait tu te pencher sur le code source de sshd pour comprendre ce voulait dire le programmeur.

En lançant sshd avec l'option "-D" tu peux voir à l'écran les connexions qui se produisent, éventuellement rajouter "-d" aussi pour des informations de débogage additionnelles (mais une seule connexion sera permise).

Tu as quelles craintes ?


Dal

cazersose · Answer

la j'ai récupéré   les logs dans var/log/messages et j'ai une erreur : 
fatal: Read from socket failed: Connection reset by peer
es que tu me conseille de désinstaller openssh et de télécharger les sources et de compiler

[Dal] · Answer

Re,

fatal: Read from socket failed: Connection reset by peer
es que tu me conseille de désinstaller openssh et de télécharger les sources et de compiler

Ces messages sont courants et ne sont pas alarmants non plus. Quand la connexion est négociée, il ne peut que le client, qui avait initialement sollicité une connexion ssh, pour laquelle sshd a affecté un processus, ait un problème de communication avec le serveur et réinitialise la connexion. Le résultat est que sshd, de son côté, a un processus qui ne sert plus à rien et il te signale donc, dans les logs, qu'il y met fin (d'où le terme "fatal"), ce qui est une bonne chose, car cela libère la mémoire.

Les causes peuvent être multiples. Après tout, le réseau, c'est des fils, c'est comme une autoroute, il peut y avoir des embouteillages, des fils défaillants, des matériels, de logiciels chargés de négocier la connexion qui sont bogués, voire des systèmes d'exploitation (c'est une connexion ssh à partir de Windows ?).

Si tu ne veux pas avoir ce genre de messages, le mieux est de désinstaller Linux et de débrancher ton câble réseau :-)

Sérieusement, tu peux tenter de diagnostiquer le problème en lançant sshd avec les options indiquées plus haut ou avec un sniffeur réseau, mais sauf à ce que tu aies vraiment des problèmes de communication visibles et gênants, ce n'est probablement pas la peine de se donner tout ce mal.

Si tu veux sécuriser sshd, assure toi d'avoir toujours la dernière version en le mettant régulièrement à jour avec ton système de paquets, et dans les options dans /etc/ssh/sshd_config ... mets au moins :

PermitRootLogin no

et règle AllowUsers sur les utilisateurs limitativement autorisés à se loguer par ssh (séparés par des espaces).

Lis man sshd_config pour plus de détails.

Tu peux aussi le mettre sur un autre port que le port 22. C'est souvent suffisant pour décourager les personnes qui trouvent très amusant de scanner des plages d'adresses IP au hasard à la recherche du port standard 22.


Dal

cazersose · Answer

merci de ces conseils mon seul souci est que la connection entre le client et le serveur soit instable ce qui a pour conséquence que l'opération de dépôt de fichier ne s'effectue pas   mais encore une fois c'est aléatoire des fois je passe et des fois non alors es qu'il est possible de mettre un champs dans sshd_config corriger ça

cazersose · Answer

j'ai mis TCP keaplive a yes(sshd_config) mais ça régle pas le problème

[Dal] · Answer

Par défaut il est déjà à "yes". En fait, tu devrais peut être tenter de le mettre à "no", mais c'est au risque d'encombrer la mémoire avec des processus fantômes (cf. man sshd_config)

Ce serait bien que tu fasses part de ton problème dès le début, on éviterait de jouer aux devinettes.

Tu transfères un fichier avec ssh (scp ?) ?

Il fait quelle taille ?

Quand il "ne passe pas", qu'arrive-t-il ? Y a-t-il des messages d'erreur ?

Peut-être le MTU est-il mal réglé sur ta machine. Voir :

http://www.commentcamarche.net/forum/affich 2210477 optimiser le mtu sous linux
http://www.commentcamarche.net/faq/sujet 7185 introduction au mtu

Pour le transfert de fichiers, surtout s'ils sont gros, qu'ils changent souvent et que tu ne veux pas avoir à retransférer la totalité alors que seule une partie a changé, il peut être préférable d'utiliser rsync (qui peut utiliser ssh), ou xdelta ou bsdiff et bspatch pour générer des fichiers de différences et ne transférer que cela (ce sont des sortes de "diff", mais pour des fichiers binaires).

Sinon, pour le transfert de gros fichiers, ftp marche très bien.


Dal

cazersose · Answer

j'ai le transfert journaliers de fichiers sur cette machine et c'est des CSV zipper alors la taille c'est pas le problème mais c'est une question de connexion , suite a une panne de courant rien ne marche j'ai le net je suis en ip fixe je me connecte sur cette machine 1/3  grace aà un client putty win et serveur fedora

cazersose · Answer

je viens de me connecter sans problèmes mais dans 2 min ça marchera plus

cazersose · Answer

voila le grand probleme  :
Oct  6 14:19:09 acserver2 sshd[2436]: Accepted password for arnaud from 172.19.1.205 port 1825 ssh2
Oct  6 14:19:38 acserver2 sshd[2474]: Accepted password for arnaud from 172.19.1.205 port 1872 ssh2
Oct  6 14:19:55 acserver2 sshd[2511]: Accepted password for arnaud from 172.19.1.205 port 1874 ssh2
Oct  6 14:21:27 acserver2 sshd[2550]: Accepted password for arnaud from 172.19.1.205 port 1916 ssh2
Oct  6 14:23:19 acserver2 sshd[2590]: Accepted password for arnaud from 172.19.1.205 port 1935 ssh2
Oct  6 14:31:04 acserver2 sshd[2745]: fatal: Read from socket failed: Connection reset by peer
Oct  6 14:31:07 acserver2 sshd[2866]: Accepted password for arnaud from 172.19.1.205 port 2038 ssh2
Oct  6 14:31:26 acserver2 sshd[2906]: Accepted password for arnaud from 172.19.1.205 port 2039 ssh2


j'ai une socket failled au millieu

[Dal] · Answer

Salut,

Le message "fatal: Read from socket failed" est pour le processus ssh [2745]

Peux-tu faire :

grep "sshd$$2745$$"

sur tes logs pour voir ce qui sort en relation avec ce processus ?

Pourquoi as-tu autant de connexions de "arnaud" ? .. une toutes les 30 secondes ... ?

As-tu essayé de lancer sshd avec les options "-d -D" comme je te le disais (arrête le avant) ?

Mets LogLevel à DEBUG3 (ou la valeur maximale pour ton système, cf. man sshd_config), relance sshd et vois si tu as plus de détails.


Dal

cazersose · Answer

voila commande que tu m'as demandé :
[root@acserver2]~>service sshd stop
Arrêt de sshd :                                            [  OK  ]
[root@acserver2]~>/usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.7p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 172.19.1.184.
Server listening on 172.19.1.184 port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 172.19.1.205 port 1768
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user arnaud service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "arnaud"
debug1: PAM: setting PAM_RHOST to "172.19.1.205"
debug1: PAM: setting PAM_TTY to "ssh"



sur cette connexion je suis pas passé (pas de connection )

cazersose · Answer

j'ai une question pourquoi il cheche a faire un fork :


debug1: Server will not fork when running in debugging mode.

[Dal] · Answer

1.

j'ai une question pourquoi il cheche a faire un fork :
debug1: Server will not fork when running in debugging mode.

C'est indiqué dans la page de manuel. Lorsqu'il est démarré en mode "debug", sshd n'accepte qu'une seule connexion et ne crée pas de nouveau process (c'est à dire il ne fait pas un fork pour chaque nouvelle connexion, un processus traite une connexion). Un seul utilisateur à la fois peut donc se loguer. Cet avertissement est normal.

2.

debug1: userauth-request for user arnaud service ssh-connection method none 

est plus préoccupant ... as-tu mis "PasswordAuthentication No"dans sshd_config ? Il doit être mise à "Yes" si tu veux permettre l'authentification par mot de passe.

Il n'y a rien après  la dernière ligne "debug1: PAM: setting PAM_TTY to "ssh" " ?

Si tu as cette option dans ton sshd, mets aussi "ChallengeResponseAuthentication Yes".

Peux-tu poster ton sshd_config ?

Arnaud est un utilisateur réel, avec un compte ?

Tu lances quoi comme commande, côté client ?

Peux-tu lancer la commande en mode verbeux ? (par exemple "ssh -v" pour ssh)

.. le plus étrange est que tu sembles indiquer que le problème est aléatoire ... :-/


Dal

cazersose · Answer

bonjour, mon problème est aléatoire oui  je reçois des connection refused de maniére aleatoire .
pour le client c'est un putty donc meme quand la clé public change putty le détecte  .
et oui  le compte arnaud existe vraiment  sur la machine 



/****************************************************************************************/
///                        SSHD_config                                                                                                            ///
/***************************************************************************************/
#	$OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm 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 172.19.1.184

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require 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 768

# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
#SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

LoginGraceTime 2m
PermitRootLogin yes
StrictModes yes
MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

# 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 yes

# 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 yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

# 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
#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 delayed
ClientAliveInterval 15
ClientAliveCountMax 45
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

# 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

[Dal] · Answer

Salut,

Tu as bien "PasswordAuthentication yes"...

Si ton problème est aléatoire, il est peut-être ailleurs que dans la configuration de sshd.

Cherche du côté de la carte réseau (essaye de régler le MTU), cherche du côté des équipements et passerelles qui peuvent séparer ta machine windows de ton serveur sshd.

Est-ce que cela n'affecte que les connexions ssh ? quid des autres connexions ?

Un ping passe-t-il toujours ou lui arrive-t-il de rester bloqué (pour autant que le firewall de ton serveur ne bloque pas les requêtes icmp) ?

Essaye de faire un traceroute de ton client vers le serveur et voie se cela bloque quelque part entre ta machine et le serveur, alors que cela ne devrait pas (avec la même réserve appliquée aux machines sur la route).

Elles sont loin tes machines, l'une de l'autre.. la route est-elle longue ? Le problème est peut-être sur le chemin.


Dal

bob031 · Answer

salut,

ne serait-ce pas le même problème résolu ici ?
https://forums.fedora-fr.org/viewtopic.php?pid=301152

Des troubles sshd - Page 2

Discussions similaires

Newsletters