Openssh Et Acces Root

[cly]

Bonsoir,

Suite a un ipkg upgrade, le paquet openssh a ete mis a jour, ainsi que /opt/etc/sshd_config, sans me demander la permission!

J'ai pu facilement remettre a jour le numero de port que j'utilisais pour cette 2eme instance (en plus de celle d'origine, sur le port 22), mais je n'arrive pas a me connecter en tant que root avec cette instance d'openssh (avec celle de syno c'est OK).

Je ne me souviens plus si ca marchait avant mon upgrade ou pas... J'ai beau forcer PermitRootLogin yes, ca ne change rien.

C'est normal?

[cricx]

Il faut aussi red

[cly]

oui, bien sur j'ai fait un /opt/etc/init.d/S40sshd restart

je me prends:

Permission denied, please try again.

et il n'y a rien dans les logs (dans /var/log, car /opt/var/log n'existe pas)

Pour un compte non root, ca fonctionne.

[cricx]

oui, bien sur j'ai fait un /opt/etc/init.d/S40sshd restart

je me prends:

Permission denied, please try again.

et il n'y a rien dans les logs (dans /var/log, car /opt/var/log n'existe pas)

Pour un compte non root, ca fonctionne.

peux-tu donner ton sshd_config ?

es-tu s

[MS_Totor]

salut

c'est un problème classique la commande cp est désactivée dans oepnssh du syno, en installant openssh ipkg qui l'integre, il y a deux instances ssh donc erreur, et message d'erreur denied pour root,

par exemple: quand tu édite un fichier du syno en root via wincsp

de façon transparente, ce fichier est transféré sur le pc pour y être édité, puis re transmis au syno, il y a donc utilisation de copie.(cp) hors, cp n'est pas actif du point de vue du syno, donc la fonction est interdite, même à root, donc denied....cqfd

openssh ipkg ne peut démarrer voir pourquoi ci dessous

il faut que tu regarde tes log , dmesg

car si il y a deux instances différentes de ssh sur la même interface réseau et sur le même port,

vu la séquence de démarrage des services l'instance ssh de ipkg ne peut être lancée, l'adresse étant déjà prise, bind adresse impossible à monter, error.. et cela fiche le souc....car cp ne peut pas être activé.

donc, tu utilise l'un ou l'autre, si les deux tu es obligé de changer dans sshd_config de ipkg situé dans /opt/etc/ le numéro de port en 2222 par exemple puis de relancer openssh de ipkg situé dans /opt/etc/init.de de mémoire., puis de redémarrer ssh natif via DSM ou de l'arrêter

sinon deux ports ssh à gérer, le 22 et le 2222.

comme le dit crixc il est inutile d'avoir les deux serveurs ssh sur deux ports différents, il vaut mieux installer le paquet sftp de ipkg, pour faire du cp et donc compléter openssh natif, cela est expliqué sous forme de tuto dans le forum il me semble.

il suffit de changer le chemin vers le serveur sftp dans sshd_config natif après installation de sftp,

ce chemin est bien là mais pointe vers un sftp qui n'est pas au bon endroit.

sftp de ipkg comme tout paquet ipkg est installé dans /opt

une fois le chemin corrigé, tu redémarre ssh via DSM et hop

le soucis sera réglé et cp actif

il n'y avais aucune explication du pourquoi sur le forum, je me suis dit que l'expliquer un peu ne fais pas de mal

[cly]

<br />peux-tu donner ton sshd_config ?<br /><br />es-tu s

[MS_Totor]

non je n'utilise plus deux instances, je n'en utilise qu'une seule et c'est largement suffisent

ssh natif chez moi est désactivé, et je n'utilise quasi plus aucun des outils fournit en shell natif, vu que j'utilise une busibox compilée à ma sauce et bien plus complète que celle fournie,

au final, n'ayant pas tenté un chroot debian, j'ai abordé le soucis à la source, mon syno n'est plus trop geré de la même facon que les vôtres, donc parfois difficile de comparer.....

j'utilise sudo pour la gestion root, l'accès de root lui même est interdit via ssh comme sur une debian.

pour ton soucis qui m'est déjà arrivé plusieurs fois et seulement s i j'avais deux instances, il y de a cela longtemps, de mémoire il suffit en général de relancer ssh natif du syno via dsm, activation, désactivation de ssh, pour que l'accès root ne soit plus denied, j'ai laissé tombé depuis ce principe.

penses peut être aussi à modifier le chemin dans sshd_natif pour pointer sur sftp à l'identique que pour openssh ipkg, ceci explique peut être

cela..

sans log difficile de t'aider là plus loin là

[cricx]

<br /><br /><br />

Oui, je suis sur du mot de passe, il fonctionne quand je me connecte au port 22, avec le sshd d'origine donc. A moins que le sshd d'ipkg n'interroge pas correctement /etc/shadow?

J'ai installe l'openssh d'ipkg pour avoir sftp et scp qui fonctionnent, et comme indique ailleurs sur ce forum, ca peut etre interessant d'avoir 2 sshd sur 2 ports differents avec des possibilites differentes.

(ex )

Pour le sshd_config, je n'ai rien change a part le no de port: /opt/etc/openssh/sshd_config:

Port 5022

#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


# Lifetime and size of ephemeral version 1 server key                           

#KeyRegenerationInterval 1h

#ServerKeyBits 1024                                                    


# Logging                                                          

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO


# Authentication: 


#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes                                        

#MaxAuthTries 6

#MaxSessions 10


#RSAAuthentication yes                

#PubkeyAuthentication yes        

#AuthorizedKeysFile     .ssh/authorized_keys                  


# For this to work you will also need host keys in /opt/etc/openssh/ssh_known_ho

#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


# Change to no to disable s/key passwords               

#ChallengeResponseAuthentication yes


# 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                                              


#AllowAgentForwarding yes

#AllowTcpForwarding yes         

#GatewayPorts no                      

#X11Forwarding no                

#X11DisplayOffset 10                                          

#X11UseLocalhost yes                      

#PrintMotd yes                                                                  

#PrintLastLog yes                                                               

#TCPKeepAlive yes               

#UseLogin no                                                           

UsePrivilegeSeparation no                                     

#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


# Example of overriding settings on a per-user basis

#Match User anoncvs                                                             

#       X11Forwarding no                                                        

#       AllowTcpForwarding no   

#       ForceCommand cvs server                                        

En reponse a MS_totor, je n'ai pas de souci pour demarrer la 2eme instance, vu qu'elle tourne sur un port different, le pb n'est pas la (le 2eme sshd repond bien avec un user non-root)

Toi qui utilises 2 instances de sshd, tu arrives donc a te loguer root avec les deux?

essaie d'enlever le #

[MS_Totor]

punaise je n'avais m

[ayukar]

je suis assez intéressé par un truc se rapprochant du ssh de debian ms_totor tu as fait comment pour installer ca?

comme toi j'utilisais le sudo pour le root et j'avais de vrai mot de passe sur les user rajouté j'avoues ca me manque pour mon syno

[MS_Totor]

salut

est ce que au moins la correction à faire dite par crirxc est ok ? tout est rentré dans l'ordre ?

car tu ne réponds pas en fait pour savoir ou tu en es et tu passes à une autre question ensuite

pour sudo etc..

juste à titre d'information et à prendre comme tel pour entamer tes recherches

sudo est dispo en paquet ipkg, à bien piger, en terme de sécurité, pour autoriser quelqu'un à utiliser un accès root , (su - ou sudo - etc...) donc s'élever en privilèges root via un user système, debian diffère d'ubuntu, un nouvel utilisateur à par le premier pour créer le système, n'a pas accès à root comme cela, et heureusement, et, est géré via une liste d'user autorisé, voir sudoers, surtout bien comprendre les modifications à réaliser et l'impact pour le syno, cela avant toute manip, et aux risques et périls qui vont avec.

à partir d'un système ou l'accès root est accessible par sudo, via ssh on doit désactiver la possibilité de login root, but de la manip en terme de sécu de base pou ssh, sans aborder le sujet des clés et changement de port d'accès qui vont avec..

vu l'impact très négatif en cas de mauvaises manip, donc dangereux, je ne donne pas plus d'info sur la chose, ni sur le forum ni via mp, merci de faire ta propre approche de la chose avec les éléments fournis qui te donnent déjà pas mal d'infos.

@+

[ayukar]

Merci bien de ta r

[cly]

salut

est ce que au moins la correction

[cricx]

Merci bien de ta r

[cricx]

Heu non, ce n'est pas moi qui ai pos

[cly]

en g

[cricx]

Merci pour la suggestion mais comme ce mot-cle n'est pas specifie dans ma conf, ca ne change rien.

J'ai lance les 2 sshd avec les options de debug, et rien ne me saute aux yeux: je constate qu'il y a plus de messages en "debug3" dans le openssh (5.2p1) de Synology que dans celui d'ipkg (5.5p1).

Avec celui de Syno:

debug1: userauth-request for user root service ssh-connection method password

debug1: attempt 3 failures 2

debug2: input_userauth_request: try method password

debug3: mm_auth_password entering

debug3: mm_request_send entering: type 10

debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD

debug3: mm_request_receive_expect entering: type 11

debug3: mm_request_receive entering

debug3: monitor_read: checking request 10

debug3: auth_shadow_pwexpired: today 14868 sp_lstchg 10933 sp_max 99999

debug3: mm_answer_authpassword: sending result 1

debug3: mm_request_send entering: type 11

Accepted password for root from 192.168.0.3 port 43658 ssh2

Avec celui d'ipkg:

debug1: userauth-request for user root service ssh-connection method password

debug1: attempt 3 failures 2

debug2: input_userauth_request: try method password

debug3: auth_shadow_pwexpired: today 14868 sp_lstchg 10933 sp_max 99999

Failed password for root from 192.168.0.3 port 45665 ssh2

Moralite, j'ai recupere les sources des 2 versions, et j'essaie de comprendre ce qui differe. J'ai essaye de compiler la version 5.5p1 en natif sur le Syno, mais il me manque pas mal de packages -dev pour arriver au bout. Vous savez si on peut recuperer les anciens packages ipkg quelque part? Je voudrais essayer de re-installer la version que j'avais avant mon upgrade, il se pourrait qu'il y ait un pb avec ce paquet. (Il y en a un avec la nouvelle version de squid, qui est une regression par rapport a la precedente que j'avais installee precedemment, le paquet courant ressort le message d'erreur

 

comm_select_init: epoll_create(): (38) Function  not implemented

qui etait corrige par un paquet binaire que j'avais recupere ailleurs, mais je ne sais plus ou :-)

tu as regard

[cly]

tu as regard

[MS_Totor]

par defaut sur tous les synos , le password de root et admin sont identiques, donc regardes en premier ce que tu as modifié de ce côté.

exemple si à un moment tu a fais un "password" connecté root via ssh, il y a impact sur le mot de passe root et celui admin ?

pour rappel au cas ou tu n'y aurais pas pensé, je n'ai pas decortiqué la facon dont interagissent les actions qui suivent réellement ni la facon dont est géré le pass admin

essayes de changer le mot de passe de admin via DSM, cela change celui de root sur un syno non modifié

si tu avais sauvegardé le fichier de configuration avant tes manip, tu devrais pouvoir revenir un peu en arriere, cela inclus la liste des users et leurs password

PS: de mémoire car ma vm de dev est hs, server en vrac, la fonction epoll doit etre desactivée dans tous les paquets compilés nativement ou en cross compilation

Modifié le 21 septembre 2010 par MS_Totor

[cly]

Alors voici le resultat des experiences:

- changement de password 'admin' depuis DMS: ca ne change que celui d'admin, pas de root

- changement de password 'root' depuis un shell: ca ne change que celui de root

j'ai du avoir un truc bizarre, du style j'ai oublie que j'avais change le password de root parce que l'ancien marchait toujours avec le ssh de Syno...

Mais comment faites-vous, les autres qui ont l'openssh d'ipkg? Vous ne changez jamais le password de root/admin?

[cricx]

Alors voici le resultat des experiences:

- changement de password 'admin' depuis DMS: ca ne change que celui d'admin, pas de root

- changement de password 'root' depuis un shell: ca ne change que celui de root

j'ai du avoir un truc bizarre, du style j'ai oublie que j'avais change le password de root parce que l'ancien marchait toujours avec le ssh de Syno...

Mais comment faites-vous, les autres qui ont l'openssh d'ipkg? Vous ne changez jamais le password de root/admin?

finalement,

[cly]

finalement,

[ayukar]

euh pour te répondre crix

/root $ passwd

sh: passwd: not found

ou en normale

adduser: cannot execute passwd, you must set password manually

voila...........donc ben la commande passwd ,ipkg ,sudo et adduser installer

[cricx]

finalement, ce que je disais dans mon post du 16 septembre 2010 - 09:09 n'

[ayukar]

concernant le ssh du syno?ton message a 8h09