Questions Sur Ssh Et Sftp

[Amsonia]

Merde!!!

j'ai voulu installer ssh optware pour t'aider et voila le résultat juste apres le "ipkg install"

root@fserv> ls -l / | grep etc

ls: cannot access /etc: No such file or directory

d????????? ? ? ? ? ? etc

drwxr-xr-x 15 0 0 4096 2012-09-04 10:59 etc.defaults

ah euh…oups ?

activation de telnet pour "ipkg remove openssh" ?

[MrWaloo]

Merde!!!

j'ai voulu installer ssh optware pour t'aider et voila le résultat juste apres le "ipkg install"

root@fserv> ls -l / | grep etc

ls: cannot access /etc: No such file or directory

d????????? ? ? ? ? ? etc

drwxr-xr-x 15 0 0 4096 2012-09-04 10:59 etc.defaults

Oh lala...

which ls[/code]

Pour voir... et si jamais, tu sauras quoi faire

Modifié le 11 septembre 2012 par MrWaloo

[CoolRaoul]

ah euh…oups ?

activation de telnet pour "ipkg remove openssh" ?

telnet, sans acces a /etc/passwd, c'est pas gagné...

J'ai lancé un "/sbin/reboot" et on verra l'étendue des dégats ce soir a la maison ....

[CoolRaoul]

Je le crois pas: il est de retour et rien n'est cassé!

fserv login: root


Password:



BusyBox v1.16.1 (2012-08-30 00:05:10 CST) built-in shell (ash)

Enter 'help' for a list of built-in commands.


root@fserv> uptime

16:20:06 up 5 min, load average: 0.71, 1.17, 0.58

[CoolRaoul]

Bon, apres ces frayeurs, reprenons...

la connexion est refusée parce que je n'ai pas générée de clef pour l'user root, juste pour mon laptop.

Comprend pas ce que tu veux dire par la..

Je n'ai pas dit qu'openssh ne marchait pas, c'est le sshd de syno qui n'accepte pas le binaire sftp d'optware comme on l'a dit.

maintenant que le tu n'utilises plus le sshd de syno, on peut déja oublier ce problème-là

1/je n'arrive pas à arrêter le service proprement (juste par la commande kill)

Aucune importance, a la limite tu fait un "killall sshd"

2/ j'ai mon /var/log/messages rempli de

Sep 11 16:06:34 sshd[28160]: error: Could not load host key: /opt/etc/openssh/ssh_host_ecdsa_key

Sep 11 16:06:35 sshd[28185]: error: setlogin failed: Function not implemented

la commande suivante devrait résoudre le probleme

ssh-keygen -t ecdsa -C '' -N '' -f /opt/etc/openssh/ssh_host_ecdsa_key[/code]

3/ je donnais les liens vers ma config, si jamais qqn voyait un truc pas net

4/ la commande uptime foirée, ça, c'est réglé

Er bien quels sont les problemes restants alors?

Modifié le 11 septembre 2012 par CoolRaoul

[Amsonia]

Ouf, désolé pour la frayeur !

0/

NAS> ssh root@localhost -p 49442

Permission denied (publickey).

Ce qui me semble plutôt bon signe puisque si j'ai généré une clef publique pour identifier l'ordi avec lequel je me connecte en ssh sur le nas comme indiqué ici, je n'ai pas fait cette manipulation pour l'utilisateur root du nas donc il s'éjecte lui-même. 1/ ok, va pour la méthode barbare 2/ ta commande a généré la clef mais j'ai toujours des tonnes de

Sep 11 16:06:35 sshd[28185]: error: setlogin failed: Function not implemented[/code]

3/ …

4/ ok

[CoolRaoul]

0/

NAS> ssh root@localhost -p 49442

Permission denied (publickey).

Ce qui me semble plutôt bon signe puisque si j'ai généré une clef publique pour identifier l'ordi avec lequel je me connecte en ssh sur le nas comme indiqué ici, je n'ai pas fait cette manipulation pour l'utilisateur root du nas donc il s'éjecte lui-même.

En effet, essaie avec un compte non root et saisit le mot de passe lorsque le système le demande:

ssh <username>@localhost

pour confirmer que le login est possible

2/ ta commande a généré la clef mais j'ai toujours des tonnes de

Sep 11 16:06:35 sshd[28185]: error: setlogin failed: Function not implemented[/code]

je l'avais oublié celui la, que veux tu dire par 'des tonnes': un message pour chaque tentative de login ou ca continue meme si tu ne fait pas de test?

[Amsonia]

J'ai modifié ma config ssh pour accepter les connexions par mot de passe, j'ai killall sshd, activé le telnet et me suis connecté en root, relancé le service /opt/etc/init.d/S40sshd, me suis connecté en root en ssh pour tester si le service était bien lancé et ai essayé de ssh root@localhost => permission denied.

J'ai donc réessayé de me connecter mais en admin et ça marche :

NAS> ps | grep ssh

6733 root	 4508 S	/opt/sbin/sshd

7163 root	 4588 S	sshd: root@pts/0

8321 root	 4440 S	ssh admin@localhost -p 49442

8322 root	 4508 S	sshd: admin@pts/1

8774 root	 4588 S	sshd: root@notty

8952 admin	 2964 S	grep ssh

Donc oui, ça marche. D'ailleurs, quelque que cela prouve ? Quant à la ligne , sshd[20462]: error: setlogin failed: Function not implemented voici les quelques dernières lignes. Comme tu peux le voir, ça s'accumule sans arrêt.

Sep 11 21:54:30 sshd[20462]: error: setlogin failed: Function not implemented

Sep 11 21:54:30 sshd[20469]: error: setlogin failed: Function not implemented

Sep 11 21:54:31 sshd[20475]: error: setlogin failed: Function not implemented

Sep 11 21:54:31 sshd[20508]: error: setlogin failed: Function not implemented

Sep 11 21:54:40 sshd[20744]: error: setlogin failed: Function not implemented

Sep 11 21:54:40 sshd[20751]: error: setlogin failed: Function not implemented

Sep 11 21:54:40 sshd[20753]: error: setlogin failed: Function not implemented

Sep 11 21:54:50 sshd[21054]: error: setlogin failed: Function not implemented

Sep 11 21:54:50 sshd[21061]: error: setlogin failed: Function not implemented

Sep 11 21:54:50 sshd[21063]: error: setlogin failed: Function not implemented

Sep 11 21:54:56 sshd[21225]: error: setlogin failed: Function not implemented

Sep 11 21:54:56 sshd[21228]: error: setlogin failed: Function not implemented

Modifié le 11 septembre 2012 par Amsonia

[CoolRaoul]

J'ai modifié ma config ssh pour accepter les connexions par mot de passe, j'ai killall sshd, activé le telnet et me suis connecté en root, relancé le service /opt/etc/init.d/S40sshd, me suis connecté en root en ssh pour tester si le service était bien lancé et ai essayé de ssh root@localhost => permission denied.

D'abord essayer de mettre

PermitRootLogin yes 

dans le fichier sshd_config sinon y ajouter

LogLevel DEBUG[/code]




recommencer la tentative de connexion et regarder dans /var/log/messages si on trouve des indications sur la cause

(relancer sshd a chaque modif)



Tu peux faire un test de connexion par clé  avec une clé privée  de test provisoire:

en étant connecté root en telnet sur le syno, faire

[code] cd ~/.ssh ssh-keygen -f test -t rsa -P "" cat test.pub >> authorized_keys ssh root@localhost [/code]

J'ai donc réessayé de me connecter mais en admin et ça marche :

[code]NAS> ps | grep ssh 6733 root 4508 S /opt/sbin/sshd 7163 root 4588 S sshd: root@pts/0 8321 root 4440 S ssh admin@localhost -p 49442 8322 root 4508 S sshd: admin@pts/1 8774 root 4588 S sshd: root@notty 8952 admin 2964 S grep ssh[/code]

Donc oui, ça marche. D'ailleurs, quelque que cela prouve ?

Que ca marche justement, histoire de ne pas perdre du temps sur certaines pistes. On sait maintenant que le problème est uniquement sur le compte root.

Quant à la ligne , [font=courier new,courier,monospace]sshd[20462]: error: setlogin failed: Function not implemented [/font]voici les quelques dernières lignes. Comme tu peux le voir, ça s'accumule sans arrêt.

[code]Sep 11 21:54:30 sshd[20462]: error: setlogin failed: Function not implemented [/code]

La par contre, cela va s'avérer bien plus ennuyeux si tu ne trouves pas de solution (pas trouvé de mon coté), ça va remplir la log a vitesse Grand V

J'ai bien cherché par google sur cette erreur mais ce que je trouve semble indiquer qu'il faudrait recompiler openssh an modifiant une option... pas top.

[Amsonia]

Bon alors, retour des courses :

1/ l'activation des logs n'était pas si aisée.

Il ne suffit pas de mettre le LogLevel à DEBUG, il fallait aussi modifier le fichier etc/syslog.deny comme indiqué ici => http://glr81.free.fr...01-ssh-logs.htm

2/ je n'arrive toujours pas à me connecter en root en ssh sur le localhost

Voici un extrait de mon /var/log/messages. J'ai fait sauter toutes les lignes ne se rapportant pas à sshd (en modifiant le syslog.deny, j'ai les log du serveur mail, de transmission et d'autres qui apparaissent)

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Set /proc/self/oom_adj to 0 # aucune idée de ce que c'est

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Connection from 192.168.1.12 port 57022 # je me connecte en root depuis mon laptop

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Failed none for root from 192.168.1.12 port 57022 ssh2 # pareil, c'est quoi ce foutu "none"

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Failed publickey for root from 192.168.1.12 port 57022 ssh2 # et pourquoi là ça veut pas…

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Postponed publickey for root from 192.168.1.12 port 57022 ssh2

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05

Sep 12 11:11:15 Asimov auth.info sshd[10272]: Accepted publickey for root from 192.168.1.12 port 57022 ssh2 # …alors que là, ça accepte ? o_O

Sep 12 11:11:15 Asimov auth.err sshd[10273]: error: setlogin failed: Function not implemented # la désormais classique erreur

Sep 12 11:11:30 Asimov auth.info sshd[10659]: Set /proc/self/oom_adj to 0

Sep 12 11:11:30 Asimov auth.info sshd[10659]: Connection from 127.0.0.1 port 54599 # 1ere tentative de connexion en localhost…

Sep 12 11:11:30 Asimov auth.info sshd[10659]: Failed none for root from 127.0.0.1 port 54599 ssh2

Sep 12 11:11:35 Asimov auth.info sshd[10659]: Failed password for root from 127.0.0.1 port 54599 ssh2 #…en connexion par mot de passe

Sep 12 11:11:37 Asimov auth.info sshd[10659]: Failed password for root from 127.0.0.1 port 54599 ssh2 # je réessaye.

Sep 12 11:11:38 Asimov auth.info sshd[10659]: Connection closed by 127.0.0.1

Sep 12 11:11:42 Asimov auth.info sshd[10272]: Received disconnect from 192.168.1.12: 11: disconnected by user

Sep 12 11:11:50 Asimov auth.info login[11111]: root login on 'ttyp0' from '192.168.1.12'


Sep 12 11:13:59 Asimov auth.info sshd[12064]: Received signal 15; terminating. # modifition du sshd_config pour n'accepter que les connexions par clef et reboot du daemon

Sep 12 11:14:25 Asimov auth.info sshd[15108]: Set /proc/self/oom_adj from 0 to -17

Sep 12 11:14:25 Asimov auth.info sshd[15108]: Server listening on :: port 49442.

Sep 12 11:14:25 Asimov auth.info sshd[15108]: Server listening on 0.0.0.0 port 49442.

Sep 12 11:14:38 Asimov auth.info sshd[15439]: Set /proc/self/oom_adj to 0

Sep 12 11:14:38 Asimov auth.info sshd[15439]: Connection from 127.0.0.1 port 54687

Sep 12 11:14:38 Asimov auth.info sshd[15439]: Failed none for root from 127.0.0.1 port 54687 ssh2

Sep 12 11:14:38 Asimov auth.info sshd[15439]: Connection closed by 127.0.0.1 # échec de la tentative de connexion par clef

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Set /proc/self/oom_adj to 0

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Connection from 192.168.1.12 port 57178 # re-connexion depuis le laptop…

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Failed none for root from 192.168.1.12 port 57178 ssh2

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Postponed publickey for root from 192.168.1.12 port 57178 ssh2

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05

Sep 12 11:14:53 Asimov auth.info sshd[15811]: Accepted publickey for root from 192.168.1.12 port 57178 ssh2

Sep 12 11:14:53 Asimov auth.info sshd[15811]: subsystem request for sftp by user root # …en me connectant en sftp pour récupérer le présent log

Sep 12 11:14:53 Asimov auth.err sshd[15812]: error: setlogin failed: Function not implemented

3/ pour le setlogin failed : function not implemented, il semblerait que ça le fasse 1 fois par connexion. Or, jusqu'à présent j'utilisais sur mon laptop un petit outil appelé "GeekTools" qui me permettait d'envoyer des commandes en ssh pour récupérer des infos telles que l'uptime, le nombre de connexions par protocole, etc. La chose ouvrait plusieurs connexions ssh root en même temps et à intervalles réduits ; c'est ce qui faisait apparaître toutes ces lignes d'erreur très rapprochées dans le temps. 4/ je te colle mon /opt/etc/openssh/sshd_config :

# $OpenBSD: sshd_config,v 1.84 2011/05/23 03:30:07 djm Exp $

# This is the sshd server system-wide configuration file. See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/opt/sbin:/opt/bin:/usr/sbin:/usr/bin:/sbin:/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 override the

# default value.


Port 49442 # modif perso n°1


#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

# The default requires explicit activation of protocol 1

#Protocol 2

# HostKey for protocol version 1

#HostKey /opt/etc/openssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /opt/etc/openssh/ssh_host_rsa_key

#HostKey /opt/etc/openssh/ssh_host_dsa_key

#HostKey /opt/etc/openssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 1024

# Logging

# obsoletes QuietMode and FascistLogging

SyslogFacility AUTH # activation du log

LogLevel DEBUG # activation du log

# Authentication:

#LoginGraceTime 2m


#PermitRootLogin yes # le root login est autorisé par défaut


#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#RSAAuthentication yes


#PubkeyAuthentication yes # les connexions par clef sont autorisées par défaut


# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2

# but this is overridden so installations will only check .ssh/authorized_keys

AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /opt/etc/openssh/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 no # modif perso n°2


#PermitEmptyPasswords no

# Change to no to disable s/key passwords


ChallengeResponseAuthentication no # modif perso n°3 - modification effectuée pour coller au plus près du /etc/sshd/sshd_config de Synology


# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

#GSSAPIAuthentication no

#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 # ici le /etc/ssh/sshd_config est à 'yes' mais ça merdait alors j'ai remis la config par défaut soit 'no'.


#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no


UsePrivilegeSeparation no # paramètre par défaut du fichier même s'il est décommenté. (dans /etc/ssh/sshd_config c'est à 'yes' )


#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS yes

#PidFile /opt/var/run/sshd.pid

#MaxStartups 10

#PermitTunnel no

#ChrootDirectory none

# no default banner path

#Banner none

# override default of no subsystems


Subsystem sftp /opt/libexec/sftp-server # utilisation du sftp d'optware. paramètre par défaut du fichier même s'il est décommenté.


# Example of overriding settings on a per-user basis

#Match User anoncvs

# X11Forwarding no

# AllowTcpForwarding no

# ForceCommand cvs server

[CoolRaoul]

je n'arrive toujours pas à me connecter en root en ssh sur le localhost

Oh! j'ai oublié de spécifier la clé a utiliser dans la commande de connexion de test!

Faut faire:

ssh -i~/ssh/test root@localhost

au lieu de

ssh root@localhost[/code]

Modifié le 12 septembre 2012 par CoolRaoul

[Amsonia]

Ça fonctionne !

Connexion en ssh root depuis mon laptop puis ssh root localhost.

Par contre je n'arrivais pas à trouver la clef au départ, parce que c'est /root/.ssh/test et pas /root/ssh/test. J'ai essayé de rajouter le point qqpart dans ta commande mais je suis apparemment trop mauvais alors je me suis directement mis dans /root/.ssh/ et j'ai tapé

ssh -i/test root@localhost -p 49442

Asimov> ps | grep sshd

14921 root	  4588 S    sshd: root@pts/1

15108 root	  4508 S    /opt/sbin/sshd

16009 root	  4588 S    sshd: root@pts/0

19247 root	  4508 S    sshd: root@pts/2

20138 root	  2968 S    grep sshd

[/code]

[CoolRaoul]

Ça fonctionne !

Connexion en ssh root depuis mon laptop puis ssh root localhost.

Par contre je n'arrivais pas à trouver la clef au départ, parce que c'est /root/.ssh/test et pas /root/ssh/test. J'ai essayé de rajouter le point qqpart dans ta commande mais je suis apparemment trop mauvais alors je me suis directement mis dans /root/.ssh/ et j'ai tapé

ssh -i/test root@localhost -p 49442[/CODE]

Tu aurais fait un copier/coller a partir de mon message ("[font=courier new,courier,monospace]ssh -i~/ssh/test root@localhost[/font]") ca le faisait aussi

[Amsonia]

C'est ce que j'ai fait au début tu penses bien !

Mais ça me donnait ça :

NAS> ssh -i~/ssh/test root@localhost -p 49442

Warning: Identity file ~/ssh/test not accessible: No such file or directory.

Permission denied (publickey).

Désolé de revenir en arrière mais je ne vois pas en quoi cela nous aide que de savoir que l'on peut initier une connexion du nas sur lui-même edit : en fait ça fonctionne en faisant ça :

ssh -i ~/.ssh/test root@localhost -p 49442

(il manquait un espace après le -i et le point devant ssh) edit 2 : et voici le log de ladite connexion (même processus que lorsque je me connecte depuis le lan) :

Sep 12 13:35:06 Asimov auth.info sshd[4081]: Set /proc/self/oom_adj to 0

Sep 12 13:35:06 Asimov auth.info sshd[4081]: Connection from 127.0.0.1 port 53093

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Failed none for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Postponed publickey for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Accepted publickey for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.err sshd[4106]: error: setlogin failed: Function not implemented

Modifié le 12 septembre 2012 par Amsonia

[CoolRaoul]

C'est ce que j'ai fait au début tu penses bien !

Mais ça me donnait ça :

NAS> ssh -i~/ssh/test root@localhost -p 49442

Warning: Identity file ~/ssh/test not accessible: No such file or directory.

Permission denied (publickey).

edit : en fait ça fonctionne en faisant ça :

ssh -i ~/.ssh/test root@localhost -p 49442

(il manquait un espace après le -i et le point devant ssh)

Ah oui, j'airais pu tester de mon coté quand même ..

Désolé de revenir en arrière mais je ne vois pas en quoi cela nous aide que de savoir que l'on peut initier une connexion du nas sur lui-même

C'est une approche classique quand on veux résoudre un problème faisant potentiellement intervenir plusieurs composants (machines, boitiers, cartes, etc...) : toujours commencer si possible par limiter le périmètre au maximum, comme ici en restant sur une seule machine.

Et ca donne des résultats, la plupart du temps

En tout cas ton problème est résolu n'est-ce pas?

[Amsonia]

Oui, merci encore, j'arrive bien à me connecter en admin ou root, en ssh seul ou sftp.

Il reste ce truc de setlogin qui, à tout le moins, bouffe du log et ce processus étrange -pour moi- de connexion : d'abord ça fail puis success :-s

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Failed none for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Postponed publickey for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Accepted publickey for root from 127.0.0.1 port 53093 ssh2

[CoolRaoul]

Il reste ce truc de setlogin qui, à tout le moins, bouffe du log et ce processus étrange -pour moi- de connexion : d'abord ça fail puis success :-s

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Failed none for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Postponed publickey for root from 127.0.0.1 port 53093 ssh2

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20

Sep 12 13:35:07 Asimov auth.info sshd[4081]: Accepted publickey for root from 127.0.0.1 port 53093 ssh2

Non, ce comportement ("Failed None") est tout a fait normal. Tu peux baisser la verbosité avec la clause "LogLevel" dans sshd_config si tu veux:

http://www.openbsd.o...ery=sshd_config:

LogLevel

Gives the verbosity level that is used when logging messages from sshd(

. The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended.

Modifié le 12 septembre 2012 par CoolRaoul

[Amsonia]

tu lis dans mes pensées c'est pas possible ^^

je cherchais justement comme faire taire le daemon : QUIET donc, logique o/

Quoique…ça peut être sympa d'avoir des logs plus détaillés pour comprendre tout ce qui se passe. Je vais voir ce qu'il faut que je fasse pour avoir un LogLevel INFO ou DEBUG sur l'ensemble des services du NAS.

edit : il suffisait de faire ce que j'avais fait tout à l'heure :

éditer le fichier /etc/syslog.deny et commenter la ligne info ou debug selon ce que l'on veut.

# These priorities in this config file are not logged

# refer to syslog.h


#alert

#crit

debug

#emerg

#err

info

notice


# Always keep these setting , as these are obselete

# refer to syslog.h

error

none

warn

panic

Et ensuite, redémarrer le daemon syslog

killall syslogd && /sbin/syslogd[/code]

Modifié le 12 septembre 2012 par Amsonia

[nanucq]

Bon là c'est devenu un peu confus, même après relecture des 4 pages. J'ai tenté les anciennes méthodes sans succès ( http://forum.synology.com/wiki/index.php/How_to_setup_an_sftp-server )

En gros, que faut il fait pour accéder en SFTP à son Syno (Ipkg installé) ?

[CoolRaoul]

Bon là c'est devenu un peu confus, même après relecture des 4 pages. J'ai tenté les anciennes méthodes sans succès ( http://forum.synolog..._an_sftp-server )

En gros, que faut il fait pour accéder en SFTP à son Syno (Ipkg installé) ?

Amsonia va nous pondre un tuto mis a jour compatible avec DSM 4.1

[nanucq]

Super ça, j'attends de le lire avec impatience ...en attendant retour à Putty.

[CoolRaoul]

Super ça, j'attends de le lire avec impatience ...en attendant retour à Putty.

Euh ce n'était qu'une supposition hein ...

[Amsonia]

Euh ce n'était qu'une supposition hein ...

ahah oui pourquoi pas

[Amsonia]

Et voilà le tutoriel ==>

(on peut fermer ce sujet maintenant non ?)