[RESOLU] mettre en place 1 SSH sur 1 LAN - dans quel ordre on fait ça plize ?

Salut,

Juste pour savoir si qqn pourrait rappeler l’ordre des manips à faire ou une ch’tite URL pour mettre en place un SSH sur un LAN ?

J’ai le petit PC firewall & serveur (sans X) auquel je veux accéder depuis le PC “Desktop”
Tout ça sur l’interface eth1 LAN 192.168.0.x

Par où je commence :

  1. Server
    > 1.1) …/sshd_config (comme ici)
    > 1.2) ssh-keygen
    > 1.3) copier les clefs sur “Desktop” ? c ce que disait Incarnation sur le post le + clair que j’ai trouvé :

, mais je vois ça nulle part ailleurs ?-/

Ou comme dit lea-linux :
2) "Desktop"
> 2.1) ssh-keygen
> 2.2) Copier sa clef depuis "Desktop" sur le server

Allez, un ptit conseil pliiiize, ça urge

euh… c’est compliqué ton affaire…
chez moi j’installe le demon ssh, je le lance, et je m’y connecte par un ssh user@adresse, password et roulaiz.

La manip de likariu permet d’éviter de taper les mots de passes lorsque l’utililisateur est déjà connu (ce qui est fort pratique en réalité, et tout aussi sûr)

Ah bin justement, le démon ssh est chez le client (i.e. “Desktop” ds mon 1er post).
Et donc si tu as un ptit server sur ton LAN et que tu veux t’y connecter par ssh, et qu’il y a encore rien de configuré, comment fais-tu là ?
Ce que je sais (çacaypadur :ane: ) :

  • openssh installé sur le srever & sur le client
  • dameon sshd lancé sur le server
    Après comment on fait, avant la 1ère connection / pour la rendre possible ??

les 2 ont raisons, a part que "le post le + clair" fait des manips plus ou moins inutiles.

le principe des cles est que la cle publique de Desktop (id_dsa.pub ) doit apparaitre sur le serveur dans le fichier ~/.ssh/authorized_keys
donc le meilleur moyen pour faire ca est de copier id_dsa.pub une fois qu’elle a ete generee par ssh_keygen dans le rep ~/.ssh/ et de la renommer en authorized_keys :wink:

Ensuite tu ne recuperes sur Desktop que la cle privee (id_dsa) que tu vas renommer cle_privee_SERVER.key (si tu veux, c’est pas obligatoire).
N’oublie pas de la proteger en lecture uniquement pour ton compte.

ben si t’as une distrib pas trop strict qui configure sshd pour etre accessible de base par le mot de passe utilisateur, y’a pas de prob.
Sinon faut coller un clavier et un ecran sur le serveur.

Alors si je te suis KP2,

  • on génère sa clé ‘id_dsa.pub’ sur le client “Desktop”
  • on la copie sur le server dans /home/MON_USER/.ssh/authorized_keys
    L’autre, je pige pas ptin je dois etre bouché comme un bon Côtes du Rhône :neutre:

ps : j’ai collé un viel écran & clavier au server, mais à tapoter accroupi par terre on risque l’erreur de frappe :smiley:

tu te log en ssh comme tu te log avec ton clavier et ton écran, voilà.

ssh likairui@serveur.qui.train.par.terre
password :
likairui@serveur.qui.train.par.terre $

Si ton client ne possède pas de clé il la generera automatiquement.

Tu generes ta paire de cle ou tu veux avec l’utilitaire que tu veux pour peu qu’elles soient bien formees.
Le plus simple etant d’utiliser ssh-keygen sur ton serveur linux.

voila.
MON_USER etant l’utilisateur avec lequel tu vas te connecter a distance en ssh.

mets toi a plat ventre :smiley:

ssh likairui.a.plat.ventre.par.terre.qui.se.melange.les.doigts@serveur.tout.pourri.qui.traine.par.terre.avec.les.restes.du.dernier.mac.do $
:lol:

Ce message n’était pas conforme aux règles d’utilisation du nouveau forum :

:MDR

hihihi c pas entièrement faux pour le serveur.qui.traine.par.terre (par contre le McDo je vous le laisse :wink: )

Lithium > ton serveur était déja configuré non ?
Ici le mien.qui.traine.par.terre tourne avec ArchLinux, et rien n’est préconfiguré. Ça explique ptet pourquoi ça marche pas aussi vite chez ouam que pour toi :sweet:

KP2 > Alors peut importe de créer la clé dsa sur le client ou sur le server, du moment qu’elle soit sur les 2 machines quand on se connecte par SSH. C bien ça ? (Parce-qu’en te lisant, un coup je lis créer sur client & copier sur serveur : [quote=""]
le principe des cles est que la cle publique de Desktop (id_dsa.pub ) doit apparaitre sur le serveur dans le fichier ~/.ssh/authorized_keys
[/quote]
, et le coup d’après le contraire.)

Ça marche tj pas.

  • openssh est installé sur les 2 machines (et openssh-client sur Desktop)

  • clé ‘id_dsa.pub’ créée avec ssh-keygen sur le client, puis copiée sur le serveur.ArchLinux.par.terre ds /home/MON_USER/.ssh/authorized_keys

  • sshd lancé sur server (port 22, etc.)

Alors pourquoi j’ai ça :

ssh likairui@serveur.qui.train.par.terre
ssh_exchange_identification: Connection closed by remote host

ssh likairui@IP.du.serveur.qui.train.par.terre
ssh_exchange_identification: Connection closed by remote host

:??:

  • G bien dit à iptables d’autoriser connections SSH avec la machine Desktop sur le port 22 (iptables -A INPUT -i eth1 -s 192.168.0.x -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j LOG_ACCEPT & iptables -A OUTPUT -o eth1 -d 192.168.0.x -m state --state ESTABLISHED -p tcp --sport 22 -j LOG_ACCEPT ).

Sur serveur.qui.traine, /var/log/errors.log raconte que

Aug 22 19:53:52 gladys sshd[4547]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.

:??:
C certainement passionnant pour l’administrateur *nix né…
mais pu**n ce que c :riva: pour le ptit webmaster de devoir apprendre 4 ou 5 nouveaux softs console (ou X) pour pv bouger un doigt (enfin, pour pv monter un firewall / serveur okdak)

ben chez moi sur un poste debian et un gentoo, client et serveur tous les deux ça fonctionne.

Ca donne quoi avec un ssh -v … ?

elendal > ça donne :

$ ssh -v likairui@192.168.0.x
OpenSSH_3.9p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.0.x [192.168.0.x] port 22.
debug1: Connection established.
debug1: identity file /home/likairui/.ssh/id_dsa type 2
ssh_exchange_identification: Connection closed by remote host

NB : j’avais copié [client]~/.ssh/id_dsa & ~/.shh/id_dsa.pub sur /home/likairui/.ssh

& sur le serveur : rien dans /var/log/messages/log & ~/errors.log juste après la tentative de connection SSH depuis client

il faut faire la difference entre la creation de la cle et a qui (quelle machine) elle sera la propriete.
Tu crees une paire de cles (privee et publique). Cette paire de cle sera possedee par Desktop.
Par contre, tu peux les creer sur ton serveur (avec ssh-keygen en ligne de commande) ou sur Desktop (avec n’importe quel utilitaire capable de les pondre au bon format).
La cle privee comme son nom l’indique sera conservee et protegee exclusivement sur Desktop.
La cle publique comme son nom l’indique sera donnee aux services auxquels Desktop doit se connecter (sshd sur serveur.qui.traine.par.terre dans ton cas precis).
Si tu les crees sur le serveur, il te faut un moyen ensuite pour rapatrier la cle privee sur Desktop (logique puisque la cle publique est deja sur le serveur), si tu les crees sur Desktop alors il te faut un moyen pour copier la cle publique sur le serveur (logique aussi non ?)

ta cle publique est bien presente dans le fichier /home/likairui/.ssh/authorized_keys ? :sarcastic:

J’ai un peu de mal avec iptables mais ca semble correct.
Fais tout de meme tes tests sans filtrage sur ssh afin de n’avois qu’un probleme a regler a la fois.

As tu bien configure ton sshd_config

Mais non, c’est tres passionnant pour tout le monde.
Faut juste conserver la tete froide, bien separer les problemes et comprendre ce qu’on fait et pourquoi on le fait.

Est-ce que le démon sshd tourne bien sur le serveur ? (ps x | grep sshd)
Si oui, efface le dossier .ssh dans ton home sur ton client et rééssaye de te connecter

elendal > oui sshd est lancé.
renommé ~/.ssh sur mon client et le message est le meme sauf que ssh cherche la clé dsa 1

identity file /home/likairui/.ssh/id_dsa type -1

KP2, Ayé g bien pigé le pourquoi du comment de la génération de la clé privée & publique :ane:

  • Le prob & le message sont les memes si je stoppe iptables sur mon server.qui.traine.par.terre
    Donc, ce prob étant réglé, le prob doit être dans la config de ssh & sshd !

  • Ma cle publique est bien ds [server] /home/likairui/.ssh/authorized_keys

  • As tu bien configure ton sshd_config ?
    j’ai essayé en tous cas !
    Le voilà (moins ce qui est commenté) :

#	$OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $

### Autorisé dans iptables :
Port 22
### Protocole SSH 1 insecure :
Protocol 2
#AddressFamily any
#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 120
### Mieux vaut se connecter en user puis 'su' :
PermitRootLogin no
StrictModes yes
#MaxAuthTries 6

RSAAuthentication yes
#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
# 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

X11Forwarding no

Et /etc/ssh/ssh_config sur mon client :

#       $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
###
   IdentityFile ~/.ssh/id_dsa
###
   Port 22
### modifié de : '2,1'
   Protocol 2
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~

Host *
###     Change de 'yes'
  ForwardX11 no
###     Change de 'yes'
  ForwardX11Trusted no
###     Change de '2,1'
  Protocol 2
    StrictHostKeyChecking no
~

bien :smiley:

non non, laisse ton client tranquille !!
Lorsque tu te connectes a ton serveur, tu utilise bien la commande suivante ?
$ ssh -i /chemin/vers/ma/cle/privee likairiu@serveur.qui.traine.par.terre

ok, c’est deja une bonne chose… on progresse

on va faire un jeu : tu regardes le morceau de fichier de conf que j’ai poste et tu cherches les differences avec le tien. Bien sur tu ne prends pas en compte les commentaires.
Un indice : regarde de pres les parties en gras
:sarcastic: :lol: :lol:

Celui la je m’en fous…

KP2 > juste pour préciser que j’ai essayé aussi avec ton exemple de sshd_config, que ça marche pas --meme message.
À moins que je doive tout commenter sauf ce que tu mets ici… mais quid du port ou de protocole utilisés ?

J’ai collé le ‘ssh_config’ car vaut mieux le voir des fois que j’aurais préciser un protocole différent que dans sshd_config par ex. :ane:
Au bout de 2 jours (perdus pour mon boulot) sur SSH, j’ai du mal à piger où mais peut être le problème ?

$ ssh -v MOI@SERVER

OpenSSH_3.9p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to gladys [192.168.0.x] port 22.
debug1: Connection established.
debug1: identity file /.../.ssh/id_dsa type 2
ssh_exchange_identification: Connection closed by remote host