Bien faire fonctionner OpenSSH [Résolu]

[Bahan]

Bonjour à toutes et à tous.

Alors, j'ai un collègue qui a installé OpenSSH sur sa machine (windows NT) grâce à SSHWindows et il veut que j'aille déposer automatiquement chaque jour un fichier sur cette machine.

Je suis pour ma part sous Unix AIX 5.2 et je peux utiliser la commande sftp sans problème.

Nous voudrions pouvoir automatiser ce transfert et donc utiliser soit des clefs RSA soit des clefs DSA. Nous avons commencé par essayer avec les clefs RSA. J'ai donc généré avec ssh-keygen une clef RSA publique et sa consoeur privée. J'ai envoyé la publique à mon collègue par mail et il a ajouté cette clef à son fichier authorized_keys.

Le problème c'est que quand j'essaie de me connecter chez lui, on me demande toujours le password... Je ne comprends pas pourquoi puisque on devrait avoir comme méthode d'authentification le système de clef RSA.

Est-ce que quelqu'un a déjà fait ça et pourrait me renseigner là-dessus ?

Merci d'avance pour votre aide.

Bahan

[Tchetch]

Si tu fais :

Code :

ssh -i ta_cle_privee utilisateur@machine

Ça fonctionne ?

[Katyucha]

peux etre que dans son sshd_config (windows), il n'y a pas la méthode d'identification par clé d'utiliser.
Peux tu nous faire un copier coller de ce fichier?

[Bahan]

Code :

ssh -i ta_cle_privee utilisateur@machine

En fait, je dois me connecter via sftp. Y a-t-il moyen en ligne de commande sftp de préciser la clef privée ?

peux etre que dans son sshd_config (windows), il n'y a pas la méthode d'identification par clé d'utiliser.
Peux tu nous faire un copier coller de ce fichier?

Le voilà :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
# $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $
 
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.
 
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
 
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.
 
#Port 22
#Protocol 2,1
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::
 
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
 
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
 
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
 
# Authentication:
 
#LoginGraceTime 2m
PermitRootLogin yes
 
# The following setting overrides permission checks on host key files
# and directories. For security reasons set this to "yes" when running
# NT/W2K, NTFS and CYGWIN=ntsec.
StrictModes yes
 
RSAAuthentication no
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys
 
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes
# 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
 
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes
 
# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM yes
 
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
MaxStartups 10:30:60
 
# default banner path
Banner /etc/banner.txt
 
# override default of no subsystems
Subsystem	sftp	/usr/sbin/sftp-server

D'après ce que je vois, le RSA est désactivé au profit de l'identification DSA, non Cela expliquerait mes problèmes . J'ai aussi un fichier nommé ssh-config. Est-ce qu'il serait utile que je l'affiche ?

Bahan

[Bahan]

Nous avons fait la modification suivante dans le fichier sshd_config sur sa machine :

Code :

1
2
RASAuthentification yes
PasswordAuthentification no

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
$ /usr/local/bin/sftp -v LOGIN@DNSDESTINATAIRE
Connecting to DESTINATAIRE...
OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to DESTINATAIRE [IP] port 22.
debug1: Connection established.
debug1: identity file HOME_USER/.ssh/id_rsa type 1
debug1: identity file HOME_USER/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'DESTINATAIRE' is known and matches the RSA                                host key.
debug1: Found key in HOME_USER/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
 
                            ****USAGE WARNING****
 
This is a private computer system. This computer system, including all
related equipment, networks, and network devices (specifically including
Internet access) are provided only for authorized use. This computer system
may be monitored for all lawful purposes, including to ensure that its use
is authorized, for management of the system, to facilitate protection against
unauthorized access, and to verify security procedures, survivability, and
operational security. Monitoring includes active attacks by authorized entities
to test or verify the security of this system. During monitoring, information
may be examined, recorded, copied and used for authorized purposes. All
information, including personal information, placed or sent over this system
may be monitored.
 
Use of this computer system, authorized or unauthorized, constitutes consent
to monitoring of this system. Unauthorized use may subject you to criminal
prosecution. Evidence of unadebug1: Authentications that can continue: publickey                               ,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: HOME_USER/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: HOME_USER/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).
debug1: Calling cleanup 0x20011dbc(0x0)
Connection closed

Je ne comprends pas trop ce qui ne va pas.
j'ai bien l'impression que la vérification de la clef fonctionne, mais il me jette quand même ...

Merci d'avance pour votre aide.

Bahan