Depuis quelque temps (1 mois ?), je n'arrive plus à me connecter sur une
de mes machine par ssh. Je me connectais sans pb avec une clé RSA.
Maintenant, j'obtiens :
Depuis hier, j'ai un peu cherché sur google mais pas de réponse précise
pour ce problème. En cherchant dans la doc d'openssh-server, j'ai vu
qu'on pouvait maintenant vérifier avec quelles options sshd se lançait,
ce qui donne :
port 22
protocol 2
addressfamily any
listenaddress 0.0.0.0:22
listenaddress [::]:22
serverkeybits 768
logingracetime 120
keyregenerationinterval 3600
x11displayoffset 10
maxauthtries 6
clientaliveinterval 0
clientalivecountmax 3
permitrootlogin yes
ignorerhosts yes
ignoreuserknownhosts no
rhostsrsaauthentication no
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
rsaauthentication yes
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
UNKNOWN no
gssapiauthentication no
gssapikeyexchange no
gssapicleanupcredentials yes
gssapistrictacceptorcheck yes
passwordauthentication yes
kbdinteractiveauthentication no
challengeresponseauthentication no
printmotd no
printlastlog yes
x11forwarding yes
x11uselocalhost yes
strictmodes yes
tcpkeepalive yes
permitblacklistedkeys no
permitemptypasswords no
permituserenvironment no
uselogin no
compression delayed
gatewayports no
usedns yes
allowtcpforwarding yes
useprivilegeseparation yes
pidfile /var/run/sshd.pid
xauthlocation /usr/bin/X11/xauth
authorizedkeysfile .ssh/authorized_keys
authorizedkeysfile2 .ssh/authorized_keys2
loglevel INFO
syslogfacility AUTH
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_dsa_key
acceptenv LANG
acceptenv LC_*
subsystem sftp /usr/lib/openssh/sftp-server
maxstartups 10:100:10
permittunnel no
permitopen
Bien sûr, la machine client peut se connecter sans problème à n'importe
quelle autre machine de mon réseau. Dans le doute, j'ai supprimé les
clés RSA des 2 côtés, j'ai aussi purgé et réinstallé openssh-server,
sans succès. Avant cela, j'ai aussi échangé les fichier
/etc/ssh/sshd_config et /etc/init.d/ssh par ceux d'une autre machine (où
ssh fonctionne correctement) : pas plus de succès.
Et, bien sûr, pas de firewall activé sur la machine. Du coup, je ne sais
plus trop vers où chercher... Une idée ?
--
Claude
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2008-12-25 16:47:10 +0100, claude wrote:
Depuis quelque temps (1 mois ?), je n'arrive plus à me connecter sur une
de mes machine par ssh. Je me connectais sans pb avec une clé RSA.
Tu peux essayer des trucs du style: "ssh localhost" sur le serveur
(si tu y as accès), et voir si ça fonctionne.
Bien sûr, la machine client peut se connecter sans problème à n'importe
quelle autre machine de mon réseau.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
claude
>
Vincent Lefevre a écrit :
Tu peux essayer des trucs du style: "ssh localhost" sur le serveur (si tu y as accès), et voir si ça fonctionne.
un ssh localhost ou 127.0.0.1 ou <ip_de_la_machine> ne fonctionne pas non plus en local.
Bien sûr, la machine client peut se connecter sans problème à n'importe quelle autre machine de mon réseau.
Même config?
Oui. D'ailleurs, j'ai essayé de plusieurs PC (debian Sid pour tous), mais pas de clés RSA pour les autres PC. Ce qui, apparemment ne change pas grand-chose puisque j'ai effacé les clés sur le serveur et le client sans succès.
Entre-temps, comme il s'agit d'un vserver, j'ai procédé à une réinstallation [1] : même punition (à peu de choses près, j'ai recréé des clés RSA pour voir et décommenté à peu près toutes les options de sshd_config qui pourraient bloquer la connexion). C'est à n'y rien comprendre :(
[1] Par réinstallation, j'entends : installation d'un vserver avec la même configuration que l'autre (donc install de base + openssh-server) et modification des liens pour faire pointer ~vdirbase et compagnie vers la nouvelle installation.
voici ce que donne maintenant une tentative de connexion :
ssh 192.168.0.98 -vv OpenSSH_5.1p1 Debian-3, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.0.98 [192.168.0.98] port 22. debug1: Connection established. debug1: identity file /home/claude/.ssh/identity type -1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/claude/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/claude/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-4 debug1: match: OpenSSH_5.1p1 Debian-4 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,,zlib debug2: kex_parse_kexinit: none,,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none, debug2: kex_parse_kexinit: none, debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 119/256 debug2: bits set: 508/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.0.98' is known and matches the RSA host key. debug1: Found key in /home/claude/.ssh/known_hosts:1 debug2: bits set: 524/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/claude/.ssh/identity ((nil)) debug2: key: /home/claude/.ssh/id_rsa (0x7f2538198920) debug2: key: /home/claude/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: Next authentication method: publickey debug1: Trying private key: /home/claude/.ssh/identity debug1: Offering public key: /home/claude/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: Trying private key: /home/claude/.ssh/id_dsa debug2: we did not send a packet, disable method debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Requesting debug1: Entering interactive session. debug1: channel 0: free: client-session, nchannels 1 Read from remote host 192.168.0.98: Connection reset by peer Connection to 192.168.0.98 closed. Transferred: sent 1712, received 1912 bytes, in 0.0 seconds Bytes per second: sent 811372.7, received 906159.2 debug1: Exit status -1
A noter qu'apparemment l'échange de clés RSA ne se fait pas correctement puisque le password m'est demandé ? Les reps .ssh et leur contenu est pour fixé à 0600.
Bref, je comprend toujours pas :( -- Claude
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
>
Vincent Lefevre a écrit :
Tu peux essayer des trucs du style: "ssh localhost" sur le serveur
(si tu y as accès), et voir si ça fonctionne.
un ssh localhost ou 127.0.0.1 ou <ip_de_la_machine> ne fonctionne pas
non plus en local.
Bien sûr, la machine client peut se connecter sans problème à n'importe
quelle autre machine de mon réseau.
Même config?
Oui. D'ailleurs, j'ai essayé de plusieurs PC (debian Sid pour tous),
mais pas de clés RSA pour les autres PC. Ce qui, apparemment ne change
pas grand-chose puisque j'ai effacé les clés sur le serveur et le client
sans succès.
Entre-temps, comme il s'agit d'un vserver, j'ai procédé à une
réinstallation [1] : même punition (à peu de choses près, j'ai recréé
des clés RSA pour voir et décommenté à peu près toutes les options de
sshd_config qui pourraient bloquer la connexion). C'est à n'y rien
comprendre :(
[1] Par réinstallation, j'entends : installation d'un vserver avec la
même configuration que l'autre (donc install de base + openssh-server)
et modification des liens pour faire pointer ~vdirbase et compagnie vers
la nouvelle installation.
voici ce que donne maintenant une tentative de connexion :
ssh 192.168.0.98 -vv
OpenSSH_5.1p1 Debian-3, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.98 [192.168.0.98] port 22.
debug1: Connection established.
debug1: identity file /home/claude/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/claude/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/claude/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1p1 Debian-4
debug1: match: OpenSSH_5.1p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 508/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.0.98' is known and matches the RSA host key.
debug1: Found key in /home/claude/.ssh/known_hosts:1
debug2: bits set: 524/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/claude/.ssh/identity ((nil))
debug2: key: /home/claude/.ssh/id_rsa (0x7f2538198920)
debug2: key: /home/claude/.ssh/id_dsa ((nil))
debug1: Authentications that can continue:
publickey,password,keyboard-interactive,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /home/claude/.ssh/identity
debug1: Offering public key: /home/claude/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive,hostbased
debug1: Trying private key: /home/claude/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
Read from remote host 192.168.0.98: Connection reset by peer
Connection to 192.168.0.98 closed.
Transferred: sent 1712, received 1912 bytes, in 0.0 seconds
Bytes per second: sent 811372.7, received 906159.2
debug1: Exit status -1
A noter qu'apparemment l'échange de clés RSA ne se fait pas correctement
puisque le password m'est demandé ? Les reps .ssh et leur contenu est
pour fixé à 0600.
Bref, je comprend toujours pas :(
--
Claude
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Tu peux essayer des trucs du style: "ssh localhost" sur le serveur (si tu y as accès), et voir si ça fonctionne.
un ssh localhost ou 127.0.0.1 ou <ip_de_la_machine> ne fonctionne pas non plus en local.
Bien sûr, la machine client peut se connecter sans problème à n'importe quelle autre machine de mon réseau.
Même config?
Oui. D'ailleurs, j'ai essayé de plusieurs PC (debian Sid pour tous), mais pas de clés RSA pour les autres PC. Ce qui, apparemment ne change pas grand-chose puisque j'ai effacé les clés sur le serveur et le client sans succès.
Entre-temps, comme il s'agit d'un vserver, j'ai procédé à une réinstallation [1] : même punition (à peu de choses près, j'ai recréé des clés RSA pour voir et décommenté à peu près toutes les options de sshd_config qui pourraient bloquer la connexion). C'est à n'y rien comprendre :(
[1] Par réinstallation, j'entends : installation d'un vserver avec la même configuration que l'autre (donc install de base + openssh-server) et modification des liens pour faire pointer ~vdirbase et compagnie vers la nouvelle installation.
voici ce que donne maintenant une tentative de connexion :
ssh 192.168.0.98 -vv OpenSSH_5.1p1 Debian-3, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.0.98 [192.168.0.98] port 22. debug1: Connection established. debug1: identity file /home/claude/.ssh/identity type -1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/claude/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/claude/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-4 debug1: match: OpenSSH_5.1p1 Debian-4 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,,zlib debug2: kex_parse_kexinit: none,,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none, debug2: kex_parse_kexinit: none, debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 119/256 debug2: bits set: 508/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.0.98' is known and matches the RSA host key. debug1: Found key in /home/claude/.ssh/known_hosts:1 debug2: bits set: 524/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/claude/.ssh/identity ((nil)) debug2: key: /home/claude/.ssh/id_rsa (0x7f2538198920) debug2: key: /home/claude/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: Next authentication method: publickey debug1: Trying private key: /home/claude/.ssh/identity debug1: Offering public key: /home/claude/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: Trying private key: /home/claude/.ssh/id_dsa debug2: we did not send a packet, disable method debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Requesting debug1: Entering interactive session. debug1: channel 0: free: client-session, nchannels 1 Read from remote host 192.168.0.98: Connection reset by peer Connection to 192.168.0.98 closed. Transferred: sent 1712, received 1912 bytes, in 0.0 seconds Bytes per second: sent 811372.7, received 906159.2 debug1: Exit status -1
A noter qu'apparemment l'échange de clés RSA ne se fait pas correctement puisque le password m'est demandé ? Les reps .ssh et leur contenu est pour fixé à 0600.
Bref, je comprend toujours pas :( -- Claude
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2008-12-26 21:05:23 +0100, claude wrote:
Vincent Lefevre a écrit :
> Tu peux essayer des trucs du style: "ssh localhost" sur le serveur > (si tu y as accès), et voir si ça fonctionne.
un ssh localhost ou 127.0.0.1 ou <ip_de_la_machine> ne fonctionne pas non plus en local.
Alors essaie peut-être de régler d'abord ce problème: au moins tu es sûr que ce n'est pas dû à des paquets qui se perdent sur le réseau pour une raison inconnue.
Entre-temps, comme il s'agit d'un vserver, j'ai procédé à une réinstallation [1] : même punition (à peu de choses près, j'ai recréé des clés RSA pour voir et décommenté à peu près toutes les options de sshd_config qui pourraient bloquer la connexion). C'est à n'y rien comprendre :(
Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2008-12-26 21:05:23 +0100, claude wrote:
Vincent Lefevre a écrit :
> Tu peux essayer des trucs du style: "ssh localhost" sur le serveur
> (si tu y as accès), et voir si ça fonctionne.
un ssh localhost ou 127.0.0.1 ou <ip_de_la_machine> ne fonctionne pas
non plus en local.
Alors essaie peut-être de régler d'abord ce problème: au moins
tu es sûr que ce n'est pas dû à des paquets qui se perdent sur
le réseau pour une raison inconnue.
Entre-temps, comme il s'agit d'un vserver, j'ai procédé à une
réinstallation [1] : même punition (à peu de choses près, j'ai recréé
des clés RSA pour voir et décommenté à peu près toutes les options de
sshd_config qui pourraient bloquer la connexion). C'est à n'y rien
comprendre :(
Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Tu peux essayer des trucs du style: "ssh localhost" sur le serveur > (si tu y as accès), et voir si ça fonctionne.
un ssh localhost ou 127.0.0.1 ou <ip_de_la_machine> ne fonctionne pas non plus en local.
Alors essaie peut-être de régler d'abord ce problème: au moins tu es sûr que ce n'est pas dû à des paquets qui se perdent sur le réseau pour une raison inconnue.
Entre-temps, comme il s'agit d'un vserver, j'ai procédé à une réinstallation [1] : même punition (à peu de choses près, j'ai recréé des clés RSA pour voir et décommenté à peu près toutes les options de sshd_config qui pourraient bloquer la connexion). C'est à n'y rien comprendre :(
Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
claude
Vincent Lefevre a écrit :
Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
A force de tests, je crois que j'ai trouvé ce qui cloche : quand j'ai fais mon installation, il y a quelques mois, j'avais un hôte sur lequel j'ai installé 2 vservers. Pour que sshd fonctionne sur l'un OU l'autre des vservers, je devais alors "killer" celui de l'hôte préalablement (et avoir lancer sshd sur le vserver dans la foulée). Comme j'ai un accès physique à la machine, ce n'était pas génial mais pas catastrophique non plus.
Maintenant, je peux me connecter à l'hôte ET n'importe lequel des vservers si et seulement si le sshd de l'hôte tourne. C'est mieux, à priori, mais pas tant que ça en fait :
A/ sur un des vservers, je me connecte en ssh alors que openssh n'est pas installé, qui plus est avec le compte d'un utilisateur de l'hôte (pas d'utilisateur de ce nom sur le vserver) ; B/ sur l'autre vserver (celui qui me posait pb à la base), je suis dans l'obligation de killer sshd pour me connecter.
En fait, après tests, que je me connecte sur n'importe laquelle des IP (hôte ou vserver), je me retrouve sur l'hôte :( Ce que je ne comprend pas trop : l'un des vservers est configuré juste en serveur web (lamp classique) => je me connecte sur l'ip en ssh (mais en fait, je suis sur l'hôte). Le serveur web est accessible sur son URL/IP normale (celle du vserver). L'autre vserver est configuré avec juste openssh-server et subversion => idem pour ssh (connexion sur l'hôte) mais du coup svn+ssh ne fonctionne plus, ce qui était la raison d'être de ce vserver :(
Je vais googler un peu là-dessus mais j'ai l'impression d'être victime d'un changement (ou d'un bug) dans la façon de gérer le réseau sur les kernels vservers les plus récents (2.6.26*).
-- Claude
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre a écrit :
Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
A force de tests, je crois que j'ai trouvé ce qui cloche : quand j'ai
fais mon installation, il y a quelques mois, j'avais un hôte sur lequel
j'ai installé 2 vservers. Pour que sshd fonctionne sur l'un OU l'autre
des vservers, je devais alors "killer" celui de l'hôte préalablement (et
avoir lancer sshd sur le vserver dans la foulée). Comme j'ai un accès
physique à la machine, ce n'était pas génial mais pas catastrophique non
plus.
Maintenant, je peux me connecter à l'hôte ET n'importe lequel des
vservers si et seulement si le sshd de l'hôte tourne. C'est mieux, à
priori, mais pas tant que ça en fait :
A/ sur un des vservers, je me connecte en ssh alors que openssh n'est
pas installé, qui plus est avec le compte d'un utilisateur de l'hôte
(pas d'utilisateur de ce nom sur le vserver) ;
B/ sur l'autre vserver (celui qui me posait pb à la base), je suis dans
l'obligation de killer sshd pour me connecter.
En fait, après tests, que je me connecte sur n'importe laquelle des IP
(hôte ou vserver), je me retrouve sur l'hôte :(
Ce que je ne comprend pas trop :
l'un des vservers est configuré juste en serveur web (lamp classique) =>
je me connecte sur l'ip en ssh (mais en fait, je suis sur l'hôte). Le
serveur web est accessible sur son URL/IP normale (celle du vserver).
L'autre vserver est configuré avec juste openssh-server et subversion =>
idem pour ssh (connexion sur l'hôte) mais du coup svn+ssh ne fonctionne
plus, ce qui était la raison d'être de ce vserver :(
Je vais googler un peu là-dessus mais j'ai l'impression d'être victime
d'un changement (ou d'un bug) dans la façon de gérer le réseau sur les
kernels vservers les plus récents (2.6.26*).
--
Claude
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
A force de tests, je crois que j'ai trouvé ce qui cloche : quand j'ai fais mon installation, il y a quelques mois, j'avais un hôte sur lequel j'ai installé 2 vservers. Pour que sshd fonctionne sur l'un OU l'autre des vservers, je devais alors "killer" celui de l'hôte préalablement (et avoir lancer sshd sur le vserver dans la foulée). Comme j'ai un accès physique à la machine, ce n'était pas génial mais pas catastrophique non plus.
Maintenant, je peux me connecter à l'hôte ET n'importe lequel des vservers si et seulement si le sshd de l'hôte tourne. C'est mieux, à priori, mais pas tant que ça en fait :
A/ sur un des vservers, je me connecte en ssh alors que openssh n'est pas installé, qui plus est avec le compte d'un utilisateur de l'hôte (pas d'utilisateur de ce nom sur le vserver) ; B/ sur l'autre vserver (celui qui me posait pb à la base), je suis dans l'obligation de killer sshd pour me connecter.
En fait, après tests, que je me connecte sur n'importe laquelle des IP (hôte ou vserver), je me retrouve sur l'hôte :( Ce que je ne comprend pas trop : l'un des vservers est configuré juste en serveur web (lamp classique) => je me connecte sur l'ip en ssh (mais en fait, je suis sur l'hôte). Le serveur web est accessible sur son URL/IP normale (celle du vserver). L'autre vserver est configuré avec juste openssh-server et subversion => idem pour ssh (connexion sur l'hôte) mais du coup svn+ssh ne fonctionne plus, ce qui était la raison d'être de ce vserver :(
Je vais googler un peu là-dessus mais j'ai l'impression d'être victime d'un changement (ou d'un bug) dans la façon de gérer le réseau sur les kernels vservers les plus récents (2.6.26*).
-- Claude
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Saturday 27 December 2008 10:07:01 claude, vous avez écrit :
Vincent Lefevre a écrit : > Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
A force de tests, je crois que j'ai trouvé ce qui cloche : quand j'ai fais mon installation, il y a quelques mois, j'avais un hôte sur lequel j'ai installé 2 vservers. Pour que sshd fonctionne sur l'un OU l'autre des vservers, je devais alors "killer" celui de l'hôte préalablement (et avoir lancer sshd sur le vserver dans la foulée). Comme j'ai un accès physique à la machine, ce n'était pas génial mais pas catastrophiqu e non plus.
Maintenant, je peux me connecter à l'hôte ET n'importe lequel des vservers si et seulement si le sshd de l'hôte tourne. C'est mieux, à priori, mais pas tant que ça en fait :
A/ sur un des vservers, je me connecte en ssh alors que openssh n'est pas installé, qui plus est avec le compte d'un utilisateur de l'hôte (pas d'utilisateur de ce nom sur le vserver) ; B/ sur l'autre vserver (celui qui me posait pb à la base), je suis dans l'obligation de killer sshd pour me connecter.
En fait, après tests, que je me connecte sur n'importe laquelle des IP (hôte ou vserver), je me retrouve sur l'hôte :(
[...]
Il me semble que c'est le fonctionnement normal de vserver, ce n'est pas de la virtualisation, la partie réseau reste un tout unique. Un Vserver doit être vu comme un chroot avec des fonctionnalités en plu s.
Il faut donc que tout les programmes qui écoutent sur une adresse IP, le fasse seulement pour celle correspondant au vserver ou à l'hôte.
SSH par défaut écoute sur toutes les interfaces et IP présentes, donc celui lancé par l'hôte se réserve toutes les IPs. Ce qui explique que : - tu n'arrives pas à lancer un serveur ssh dans un vserver (le couple I P/port est déjà utilisé par l'hôte) - tu arrive sur l'hôte si tu te connecte en ssh sur une des IPs des vse rvers
C'est l'inconvénient majeur de vserver, il faut bien configurer tous les démons, hôtes et vservers, pour qu'ils écoutent sur les bonnes IP, et seulement elles.
Ça pose un problème pour un les services réseau basé sur le l'UDP ( nmbd de samba) ou du broadcast ethernet (dhcp), qui ne s'accroche pas à une IP, m ais une interface physique...
--nextPart2439148.8BjJiTcABQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Saturday 27 December 2008 10:07:01 claude, vous avez écrit :
Vincent Lefevre a écrit :
> Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
A force de tests, je crois que j'ai trouvé ce qui cloche : quand j'ai
fais mon installation, il y a quelques mois, j'avais un hôte sur lequel
j'ai installé 2 vservers. Pour que sshd fonctionne sur l'un OU l'autre
des vservers, je devais alors "killer" celui de l'hôte préalablement (et
avoir lancer sshd sur le vserver dans la foulée). Comme j'ai un accès
physique à la machine, ce n'était pas génial mais pas catastrophiqu e non
plus.
Maintenant, je peux me connecter à l'hôte ET n'importe lequel des
vservers si et seulement si le sshd de l'hôte tourne. C'est mieux, à
priori, mais pas tant que ça en fait :
A/ sur un des vservers, je me connecte en ssh alors que openssh n'est
pas installé, qui plus est avec le compte d'un utilisateur de l'hôte
(pas d'utilisateur de ce nom sur le vserver) ;
B/ sur l'autre vserver (celui qui me posait pb à la base), je suis dans
l'obligation de killer sshd pour me connecter.
En fait, après tests, que je me connecte sur n'importe laquelle des IP
(hôte ou vserver), je me retrouve sur l'hôte :(
[...]
Il me semble que c'est le fonctionnement normal de vserver, ce n'est pas de la
virtualisation, la partie réseau reste un tout unique.
Un Vserver doit être vu comme un chroot avec des fonctionnalités en plu s.
Il faut donc que tout les programmes qui écoutent sur une adresse IP, le fasse
seulement pour celle correspondant au vserver ou à l'hôte.
SSH par défaut écoute sur toutes les interfaces et IP présentes, donc celui
lancé par l'hôte se réserve toutes les IPs. Ce qui explique que :
- tu n'arrives pas à lancer un serveur ssh dans un vserver (le couple I P/port
est déjà utilisé par l'hôte)
- tu arrive sur l'hôte si tu te connecte en ssh sur une des IPs des vse rvers
C'est l'inconvénient majeur de vserver, il faut bien configurer tous les
démons, hôtes et vservers, pour qu'ils écoutent sur les bonnes IP, et
seulement elles.
Ça pose un problème pour un les services réseau basé sur le l'UDP ( nmbd de
samba) ou du broadcast ethernet (dhcp), qui ne s'accroche pas à une IP, m ais
une interface physique...
--nextPart2439148.8BjJiTcABQ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Saturday 27 December 2008 10:07:01 claude, vous avez écrit :
Vincent Lefevre a écrit : > Tu trouveras peut-être des infos en cherchant vserver ssh sur Google.
A force de tests, je crois que j'ai trouvé ce qui cloche : quand j'ai fais mon installation, il y a quelques mois, j'avais un hôte sur lequel j'ai installé 2 vservers. Pour que sshd fonctionne sur l'un OU l'autre des vservers, je devais alors "killer" celui de l'hôte préalablement (et avoir lancer sshd sur le vserver dans la foulée). Comme j'ai un accès physique à la machine, ce n'était pas génial mais pas catastrophiqu e non plus.
Maintenant, je peux me connecter à l'hôte ET n'importe lequel des vservers si et seulement si le sshd de l'hôte tourne. C'est mieux, à priori, mais pas tant que ça en fait :
A/ sur un des vservers, je me connecte en ssh alors que openssh n'est pas installé, qui plus est avec le compte d'un utilisateur de l'hôte (pas d'utilisateur de ce nom sur le vserver) ; B/ sur l'autre vserver (celui qui me posait pb à la base), je suis dans l'obligation de killer sshd pour me connecter.
En fait, après tests, que je me connecte sur n'importe laquelle des IP (hôte ou vserver), je me retrouve sur l'hôte :(
[...]
Il me semble que c'est le fonctionnement normal de vserver, ce n'est pas de la virtualisation, la partie réseau reste un tout unique. Un Vserver doit être vu comme un chroot avec des fonctionnalités en plu s.
Il faut donc que tout les programmes qui écoutent sur une adresse IP, le fasse seulement pour celle correspondant au vserver ou à l'hôte.
SSH par défaut écoute sur toutes les interfaces et IP présentes, donc celui lancé par l'hôte se réserve toutes les IPs. Ce qui explique que : - tu n'arrives pas à lancer un serveur ssh dans un vserver (le couple I P/port est déjà utilisé par l'hôte) - tu arrive sur l'hôte si tu te connecte en ssh sur une des IPs des vse rvers
C'est l'inconvénient majeur de vserver, il faut bien configurer tous les démons, hôtes et vservers, pour qu'ils écoutent sur les bonnes IP, et seulement elles.
Ça pose un problème pour un les services réseau basé sur le l'UDP ( nmbd de samba) ou du broadcast ethernet (dhcp), qui ne s'accroche pas à une IP, m ais une interface physique...
--nextPart2439148.8BjJiTcABQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
claude
Gilles Mocellin a écrit : [...]
SSH par défaut écoute sur toutes les interfaces et IP présentes, donc celui lancé par l'hôte se réserve toutes les IPs. Ce qui explique que : - tu n'arrives pas à lancer un serveur ssh dans un vserver (le couple IP/port est déjà utilisé par l'hôte) - tu arrive sur l'hôte si tu te connecte en ssh sur une des IPs des vservers
C'est l'inconvénient majeur de vserver, il faut bien configurer tous les démons, hôtes et vservers, pour qu'ils écoutent sur les bonnes IP, et seulement elles.
Ok, je comprends mieux... J'avais lu quelque chose à ce sujet, il me semble, au moment de l'installation initiale. Ce que je ne comprend pas, du coup, c'est pourquoi ça marchait avant et plus maintenant ;)
Je vais ré-essayer tout ça en modifiant les ip d'écoute de ssh (je ne l'avais fait que sur le vserver). Merci pour m'avoir rafraichi la mémoire en tout cas :)
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Gilles Mocellin a écrit :
[...]
SSH par défaut écoute sur toutes les interfaces et IP présentes, donc celui
lancé par l'hôte se réserve toutes les IPs. Ce qui explique que :
- tu n'arrives pas à lancer un serveur ssh dans un vserver (le couple IP/port
est déjà utilisé par l'hôte)
- tu arrive sur l'hôte si tu te connecte en ssh sur une des IPs des vservers
C'est l'inconvénient majeur de vserver, il faut bien configurer tous les
démons, hôtes et vservers, pour qu'ils écoutent sur les bonnes IP, et
seulement elles.
Ok, je comprends mieux... J'avais lu quelque chose à ce sujet, il me
semble, au moment de l'installation initiale. Ce que je ne comprend pas,
du coup, c'est pourquoi ça marchait avant et plus maintenant ;)
Je vais ré-essayer tout ça en modifiant les ip d'écoute de ssh (je ne
l'avais fait que sur le vserver). Merci pour m'avoir rafraichi la
mémoire en tout cas :)
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
SSH par défaut écoute sur toutes les interfaces et IP présentes, donc celui lancé par l'hôte se réserve toutes les IPs. Ce qui explique que : - tu n'arrives pas à lancer un serveur ssh dans un vserver (le couple IP/port est déjà utilisé par l'hôte) - tu arrive sur l'hôte si tu te connecte en ssh sur une des IPs des vservers
C'est l'inconvénient majeur de vserver, il faut bien configurer tous les démons, hôtes et vservers, pour qu'ils écoutent sur les bonnes IP, et seulement elles.
Ok, je comprends mieux... J'avais lu quelque chose à ce sujet, il me semble, au moment de l'installation initiale. Ce que je ne comprend pas, du coup, c'est pourquoi ça marchait avant et plus maintenant ;)
Je vais ré-essayer tout ça en modifiant les ip d'écoute de ssh (je ne l'avais fait que sur le vserver). Merci pour m'avoir rafraichi la mémoire en tout cas :)
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
