Rechercher : dans
Par :

Connexion SSH en root

Dernière réponse le 5 sep 2006 à 20:09:36 steph, le 5 sep 2006 à 08:56:43 
 Signaler ce message aux modérateurs

Bonjour,

J'essaie de connecter deux serveur hp en ssh grâce au système de clé publique/ clé privé avec l'utilisateur root.

Mais à chaque fois il demande le mot de passe. alors que pour les autres utilisateurs cela marche très bien.

est ce un problème de config?
est ce une restriction des droit pour root?

merci de votre réponse

ps ci dessous le fichier de conf:


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

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

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

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

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#CountKeyAuthBadLogins no

# Auth selection

#HostbasedAuthAllowUsers
#HostbasedAuthDenyUsers
#PubkeyAuthAllowUsers
#PubkeyAuthDenyUsers
#KerberosAuthAllowUsers
#KerberosAuthDenyUsers
#KerberosOrLocalPasswdAllowUsers
#KerberosOrLocalPasswdDenyUsers
#PasswordAuthAllowUsers
#PasswordAuthDenyUsers
#ChallRespAuthAllowUsers [pam] user1 user2 ...
#ChallRespAuthDenyUsers [pam] user1 user2 ...
#ChallRespAuthAllowUsers [bsdauth] user1 user2 ...
#ChallRespAuthDenyUsers [bsdauth] user1 user2 ...
#ChallRespAuthAllowUsers [skey] user1 user2 ...
#ChallRespAuthDenyUsers [skey] user1 user2 ...
#ChallRespAuthAllowUsers [securid] user1 user2 ...
#ChallRespAuthDenyUsers [securid] user1 user2 ...
#GSSAPIAuthAllowUsers
#GSSAPIAuthDenyUsers


#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /opt/ssh/etc/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

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

# Kerberos options
KerberosAuthentication yes
#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 mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
X11UseLocalhost no
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#EnforceSecureTTY no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

#The following are HPN related configuration options
#tcp receive buffer polling. enable in autotuning kernels
#TcpRcvBufPoll no

# allow the use of the none cipher
#NoneEnabled no

# disable hpn performance boosts.
#HPNDisabled no

# buffer size for hpn to non-hn connections
#HPNBufferSize 2048

# override default of no subsystems
Subsystem sftp /opt/ssh/libexec/sftp-server

#LogSftp no
#SftpLogFacility AUTH
#SftpLogLevel INFO
#SftpUmask
#SftpPermitChmod yes
#SftpPermitChown yes

Meilleures réponses pour « connexion SSH en root » dans :
Délais lors d'une connexion ssh sous Linux VoirLorsque vous vous connectez à un serveur ssh, le délai entre la saisie du login et du mot de passe peut être long (C'est par exemple le cas des serveur ssh sous Debian). Cela est dû à un problème de résolution de noms au niveau du serveur. Votre...
Se logguer à distance avec ssh (Linux) Voir(Pour ceux qui voudraient avoir un rappel sur SSH) Les commandes suivantes nécessitent d'avoir un compte sur la machine sur laquelle on veut se connecter et qu'un serveur SSH y soit installé. Sous Linux, la syntaxe est simple (le client...
Se logguer à distance avec ssh ( Windows ) Voir( Pour ceux qui voudraient avoir un rappel sur ssh ) Contrairement à la plupart des distributions Linux, Windows ne possède pas de client ssh en natif. Il faut donc en installer un. Pour cela plusieurs solutions : Vous pourrez en...

1

jisisv, le 5 sep 2006 à 15:32:34

Sauf erreur:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
Décommenter la ligne
#PermitRootLogin yes

Ce n'est PAS une bonne idée.
Si on doit exécuter une commande distante, autant la lancer sous un compte autre que root, non ?
C'est que le/les services sont mal configurés/implantés...
man 5 sshd_config
Johan Gates gave you the windows.
GNU gave us the whole house.(Alexandrin)

Répondre à jisisv

2

lami20j, le 5 sep 2006 à 15:50:25

Salut,

je suis d'accord avec jisisv.

En revanche si tu peux te connecter en utilisateur sur le serveur et tu connasi le mot de passe root, il ne te reste qu'à utilise su ou su - pour se connecter en root.

Si jamais ça t'interesse un openssh chroot tu peux regarder ici
linux creation environnement openssh chroot

lami20j

Répondre à lami20j

3

 jisisv, le 5 sep 2006 à 20:09:36

Je viens de'effectuer un test.
En fait, il faut mettre
PermitRootLogin no
dans /etc/ssh/sshd_config
( yes semble être le défaut)

Johan Gates gave you the windows.
GNU gave us the whole house.(Alexandrin)

Répondre à jisisv