Accès SSH (sans outil)

Cette doc couvre la connexion aux serveurs Spektrum avec le client SSH natif (OpenSSH), sans Tabby ni Termius. C'est utile quand:

• Tu veux scripter (rsync, scp, ansible, git) sans dépendre d'un GUI
• Tu es sur une machine où Tabby n'est pas installé (jumpbox, CI runner, machine d'un collègue)
• Tu veux que ssh <host> "juste marche" depuis n'importe quel terminal (PowerShell, Git Bash, WSL, cmd)

Tabby reste OK pour le quotidien

Si tu es à l'aise avec Tabby, garde-le. Cette doc n'est pas un remplacement, c'est un complément. Le fichier ~/.ssh/config décrit ici est lu aussi par Tabby, donc déclarer tes hosts une fois ici les rend dispos partout.

Pré-requis

1. Ta clef publique est déjà déposée dans LDAP - voir Accès
2. Tu connais ton username LDAP
3. Tu as ta clef privée localement (chemin connu)

Si tu n'as pas encore ta clef dans LDAP

Tu ne pourras te connecter à rien tant que ta pubkey n'est pas dans LDAP. Fais l'étape "Premier accès" de 02_access.md en premier.

Emplacement du fichier config

OS	Chemin
Windows	C:\Users\<toi>\.ssh\config (ou %USERPROFILE%\.ssh\config)
Linux	~/.ssh/config
macOS	~/.ssh/config

Si le fichier n'existe pas, crée-le. Le dossier .ssh doit déjà exister (sinon: mkdir ~/.ssh ou via l'explorateur Windows).

OpenSSH sur Windows 11

OpenSSH est inclus par défaut dans Windows 10/11. Vérifie avec:

ssh -V

Si la commande n'est pas trouvée: Settings => Apps => Optional features => OpenSSH Client.

Le fichier config Spektrum complet

Copie-colle ça dans ton ~/.ssh/config, puis remplace <ldap-user> par ton username LDAP et <chemin-clef> par le chemin vers ta clef privée.

# ============================================================
# BASTIONS - point d'entrée SSH
# ============================================================
Host nginx-internal
    HostName 84.234.26.160
    User <ldap-user>
    IdentityFile <chemin-clef>

Host nginx-prod
    HostName 83.228.201.182
    User <ldap-user>
    IdentityFile <chemin-clef>

# ============================================================
# SERVEURS LINUX - SSH direct via jump
# ============================================================
Host services-internal
    HostName 195.15.249.196
    User <ldap-user>
    IdentityFile <chemin-clef>
    ProxyJump nginx-internal

Host staging-internal
    HostName 195.15.249.221
    User <ldap-user>
    IdentityFile <chemin-clef>
    ProxyJump nginx-internal

Host apps-prod
    HostName 89.47.48.11
    User <ldap-user>
    IdentityFile <chemin-clef>
    ProxyJump nginx-prod

# ============================================================
# TUNNELS RDP / SSMS - pas de SSH dans la machine cible
# (on ouvre une session SSH sur le bastion et on forward un port)
# ============================================================

# Win-Prod    => mstsc /v:localhost:33891
Host tun-win-prod
    HostName 83.228.201.182
    User <ldap-user>
    IdentityFile <chemin-clef>
    LocalForward 33891 89.47.48.9:3389

# DB-Prod     => SSMS  localhost,14331
Host tun-db-prod
    HostName 83.228.201.182
    User <ldap-user>
    IdentityFile <chemin-clef>
    LocalForward 14331 89.47.48.14:1433

# Win-Staging => mstsc /v:localhost:33890
Host tun-win-staging
    HostName 84.234.26.160
    User <ldap-user>
    IdentityFile <chemin-clef>
    LocalForward 33890 195.15.249.213:3389

# DB-Internal => SSMS localhost,14330
Host tun-db-internal
    HostName 84.234.26.160
    User <ldap-user>
    IdentityFile <chemin-clef>
    LocalForward 14330 195.15.249.197:1433

Pourquoi des Hosts séparés pour les tunnels

On pourrait théoriquement ajouter LocalForward directement sur nginx-prod / nginx-internal, mais ça forwarderait les ports à chaque fois que tu te connectes au bastion, même quand tu veux juste un shell. Avec un Host dédié tun-*, tu choisis explicitement quand tu ouvres un tunnel.

Sur Windows, double les backslashes (ou utilise des forward slashes)

Dans IdentityFile, le chemin C:\id_clem marche sur la plupart des OpenSSH récents, mais en cas d'erreur cryptique au parsing, écris:

IdentityFile C:/id_clem

ou

IdentityFile C:\\id_clem

Permissions du fichier

Linux / macOS

chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/<ta-clef-privée>

Pas de sudo chmod

Si tu fais sudo chmod, le fichier passe en owner root et SSH refusera de le lire ("Bad owner or permissions"). Pour réparer:

sudo chown $USER:$USER ~/.ssh/config ~/.ssh/<ta-clef-privée>

Windows

OpenSSH sur Windows refuse de lire une clef privée trop "ouverte". Si tu vois WARNING: UNPROTECTED PRIVATE KEY FILE!, restreins les ACL:

icacls "C:\id_clem" /inheritance:r
icacls "C:\id_clem" /grant:r "$($env:USERNAME):(R)"

Ça enlève l'héritage et donne lecture uniquement à ton user. La clef redevient utilisable.

Utilisation au quotidien

Connexion shell

Une fois le config en place:

ssh apps-prod
ssh staging-internal
ssh nginx-prod

Pas besoin de spécifier user, IP, jump, ou clef - tout vient du config.

Copie de fichiers (scp)

# Pull depuis apps-prod vers local
scp apps-prod:/var/log/app.log ./

# Push depuis local vers apps-prod
scp ./fix.sql apps-prod:/tmp/

# Récursif
scp -r ./build/ apps-prod:/var/www/site/

rsync

Voir rsync - transfert de fichiers pour les détails. La syntaxe se simplifie énormément avec le config:

rsync -av --progress ./dist/ apps-prod:/var/www/site/

Le ProxyJump est appliqué automatiquement, pas besoin de -J.

Git via SSH

Si tu as ton GitLab interne dans le config (pas listé ici, c'est un cas séparé), git clone git@gitlab.internal.spektrum-suisse.ch:groupe/repo.git "juste marche".

Tunnels RDP - serveurs Windows

Les serveurs Windows (Win-Prod, Win-Staging) n'ont pas SSH installé. On passe par le bastion en forwardant le port 3389 vers ton localhost.

Étape 1 - ouvrir le tunnel

ssh tun-win-prod

Garde le shell ouvert

Tant que cette session SSH reste ouverte, le tunnel est actif. Si tu fermes le shell, le tunnel meurt. Tu peux travailler dans la session (par exemple htop sur le bastion) ou la laisser idle.

Mode "tunnel-only" sans shell

Si tu veux uniquement le tunnel, sans shell interactif:

ssh -N tun-win-prod

-N = pas de commande à exécuter. La session reste ouverte juste pour le forward. Ajoute -f pour la mettre en background (Linux/Mac):

ssh -fN tun-win-prod

Étape 2 - mstsc (RDP)

Tunnel	Adresse mstsc
tun-win-prod	localhost:33891
tun-win-staging	localhost:33890

mstsc /v:localhost:33891

Tu te connectes en RDP avec le compte Windows du serveur (pas ton user LDAP).

Tunnels SSMS - bases de données SQL Server

Même principe pour SSMS sur les DB-Prod et DB-Internal.

Étape 1 - ouvrir le tunnel

ssh -N tun-db-prod      # ou tun-db-internal

Étape 2 - SSMS

Dans la fenêtre de connexion SSMS:

Tunnel	Server name
tun-db-prod	localhost,14331
tun-db-internal	localhost,14330

Virgule, pas deux-points

SSMS attend host,port (avec une virgule), pas host:port. C'est une particularité du protocole TDS de SQL Server. localhost,14331 est correct, localhost:14331 ne marchera pas.

Authentification: SQL Server auth avec les credentials de la base (pas LDAP).

Tester ta config

# Connexion simple
ssh -v nginx-prod

# Tester un host derrière jump
ssh -v apps-prod

# Tester un tunnel sans même se logger
ssh -N -T tun-db-prod
# (laisse tourner, ouvre SSMS, ferme avec Ctrl+C quand fini)

Le -v (verbose) te dit exactement quelle clef est essayée, quel ProxyJump est résolu, et où ça plante si ça plante.

Contributors

Clément Favre

Changelog

Last edited about 2 months ago

View full history

b07d2bb-docs: add Crans-Montana headless and police intranets to parc inventory