-# Arhitectura SSH Curenta

-

-Acest document descrie configuratia activa din `/home/nextgen/.ssh`. Sursa versionata a proiectului este in `/home/nextgen/projects/ssh-infrastructure`; `/home/nextgen/.ssh` ramane runtime OpenSSH si nu contine repo-ul git. Ultima actualizare: 2026-05-15. Jurnalul istoric `ssh-jump-attempts.md` este obsolete si poate fi consultat doar din git.

-

-## Structura Locala

-

-```text

-/home/nextgen/.ssh/

-  config                        <- single-file generat din inventory/hosts.yaml

-  known_hosts

-  known_hosts.old

-  authorized_keys

-  keys/

-    id_ed25519

-    id_ed25519.pub

-    elastix-root.pub

-  .doc/

-    ssh-jump-architecture.md

-

-~/.local/bin/

-  ssh

-  scp

-  sftp

-```

-

-Reguli:

-

-- Proiectul versionat sta in `~/projects/ssh-infrastructure`; `~/.ssh` ramane runtime OpenSSH.

-- Cheile de identitate stau in `~/.ssh/keys`.

-- Hosturile SSH sunt definite in `inventory/hosts.yaml`, apoi generate in `generated/*.conf`.

-- `~/.ssh/config` este instalat din `generated/client.conf` prin `tools/deploy-local.sh`; nu se editeaza manual.

-- Scripturile sursa stau versionate in `scripts/` in repo.

-- `~/.local/bin/` contine copiile executabile instalate de `tools/deploy-local.sh`; nu se editeaza manual.

-- `authorized_keys`, `known_hosts` si `config` raman in radacina `.ssh`, pentru compatibilitate cu OpenSSH.

-- `j1-relay.sh`, `ssh-proxy.sh`, `ensure-ssh-agent-bridge.sh` si `ensure-ssh-jump.sh` au fost eliminate; `ssh-wrapper.sh` ruleaza clientul SSH activ pe `is-jumper`, unde se afla cheia fizica.

-

-## Wrappers locale

-

-Scripturile sursa sunt in `scripts/` in repo; `~/.local/bin/` contine copiile executabile instalate local.

-

-| Comanda | Script | Mecanism |

-| --- | --- | --- |

-| `ssh` | `ssh-wrapper.sh` | parseaza args, rezolva hostul via `ssh -G`, construieste sesiunea nested |

-| `scp` | `scp-wrapper.sh` | apeleaza `/usr/bin/scp -S ~/.local/bin/ssh` — rutarea e delegata wrapper-ului ssh |

-| `sftp` | `sftp-wrapper.sh` | apeleaza `/usr/bin/sftp -S ~/.local/bin/ssh` — idem |

-

-- Compatibilitatea SSH pentru hop-ul final este responsabilitatea serverelor `J1`/`J2`; wrapperele locale nu reproduc algoritmi, KEX, cipher-uri sau `OPENSSL_CONF`.

-- Daca PATH-ul include `~/.local/bin` inaintea `/usr/bin`, comenzile `ssh`/`scp`/`sftp` folosesc automat aceste wrappers.

-

-## Arhitectura rețelei

-

-```

-192.168.2.0/24  — rețea locală de birou

-  is-toltec  (workstation-ul local)

-  is-jumper  192.168.2.100  (gardian cheie + client VPN)

-

-10.253.51.0/24  — rețea internă companie (acces via VPN de pe is-jumper)

-  J1  10.253.51.50:25904

-  J2  10.253.51.52:25904

-  hosturi finale (voip, porta, radius etc.)

-```

-

-**is-jumper** (192.168.2.100) este pe rețeaua locală de birou — accesibil direct din is-toltec, **fără VPN**. Este un **client** VPN (nu server): prin el se obține acces la `10.253.51.0/24`. Este **gardianul cheii fizice** (card RSA 4096) deoarece deservește mai mulți utilizatori din `192.168.2.0/24`.

-

-**Cheia fizică** (cardul) este montată exclusiv pe is-jumper și expusă prin GPG agent la `/run/user/0/gnupg/S.gpg-agent.ssh`. Wrapper-ul nu mai forwardează acest socket pe mașina locală; în schimb intră pe `is-jumper`, setează `SSH_AUTH_SOCK` la socketul local de acolo și rulează de pe `is-jumper` clientul SSH către J1/J2/j1/j2.

-

-## Lanțul de acces

-

-Calea standard (VPN activ, J1):

-

-```text

-local

-  -> is-jumper (192.168.2.100, executor SSH + cheie fizica)

-  -> J1 (10.253.51.50:25904)

-  -> host final

-```

-

-Calea publică (urgențe, fără rută VPN, j1/j2):

-

-```text

-local

-  -> is-jumper (192.168.2.100, executor SSH + cheie fizica)

-  -> j1.next-gen.ro:25904

-  -> host final

-```

-

-Sesiuni interactive pe J1/J2:

-

-```text

-local -> is-jumper -> J1

-local -> is-jumper -> J2

-```

-

-Nu mai exista bridge local de agent (`/tmp/is-jumper-agent.sock`). Cheia fizica ramane folosita local pe `is-jumper`.

-

-Jumps disponibile via flaguri wrapper:

-

-| Flag | Jump | Rută | Când |

-| --- | --- | --- | --- |

-| implicit / `-J1` | J1 (10.253.51.50) | client SSH rulat pe is-jumper | standard |

-| `-J2` | J2 (10.253.51.52) | client SSH rulat pe is-jumper | failover VPN |

-| `-j1` | j1.next-gen.ro | client SSH rulat pe is-jumper | urgențe |

-| `-j2` | j2.next-gen.ro | client SSH rulat pe is-jumper | urgențe |

-

-## Scripturi

-

-### ssh-wrapper.sh

-

-Parseaza argumentele `ssh`, rezolva hostul via `ssh -G`, construieste sesiunea nested activa pe `is-jumper`:

-

-```

-exec /usr/bin/ssh is-jumper "SSH_AUTH_SOCK=/run/user/0/gnupg/S.gpg-agent.ssh ssh -A <jump_host> '<final_ssh_cmd>'"

-```

-

-Bypass automat (pass-through direct) pentru:

-- `is-jumper` / `192.168.2.100`

-- Flaguri de interogare: `-G`, `-Q`, `-V`, `--help`

-

-Pentru J1/J2/j1/j2, wrapper-ul conecteaza intai local la `is-jumper`, apoi ruleaza acolo `ssh -A` cu `SSH_AUTH_SOCK=/run/user/0/gnupg/S.gpg-agent.ssh`. Pentru hosturile finale, comanda de pe jump ruleaza inca un `ssh` catre hostul final. Pentru `scp`/`sftp`, wrapper-ul pastreaza forma de subsystem `-s ... sftp`.

-

-### scp-wrapper.sh / sftp-wrapper.sh

-

-Wrappers subtiri care injecteaza `-S ~/.local/bin/ssh` la apelul sistemului:

-

-```bash

-/usr/bin/scp -S ~/.local/bin/ssh "$@"

-/usr/bin/sftp -S ~/.local/bin/ssh "$@"

-```

-

-Rutarea este delegata integral catre `ssh-wrapper.sh`; `scp`/`sftp` raman transparente pentru utilizator.

-

-Nu mai exista scripturi active bazate pe Python, ProxyJump sau port-forwarding externe; vechiul helper Python a fost eliminat dupa ce a fost semnalat de Sentinel.

-

-## Config SSH

-

-`~/.ssh/config` este un single-file generat din `inventory/hosts.yaml`:

-

-```sshconfig

-# Generated by tools/generate-configs.py.

-# Do not edit this file directly; edit inventory/hosts.yaml.

-```

-

-Generatorul produce:

-

-| Fisier | Destinatie | Rol |

-| --- | --- | --- |

-| `generated/client.conf` | client local | config runtime pentru `~/.ssh/config` |

-| `generated/is-jumper.conf` | is-jumper | config pentru jump aliases |

-| `generated/j1.conf` | J1 | hosturi finale |

-| `generated/j2.conf` | J2 | hosturi finale |

-

-Reguli de configurare:

-

-- hosturile finale definesc doar `HostName`, `User` si `Port`;

-- pe client, hosturile importate din IFS folosesc drept `HostName` numele

-  canonic deja cunoscut pe jump, iar IP-ul ramane alias pentru autocomplete;

-- `is-jumper` defineste si cheia locala de acces (`IdentityFile`, `IdentitiesOnly`);

-- wrapperul construieste ruta nested prin `is-jumper -> J1` implicit;

-- optiunile comune per-grup (ConnectTimeout etc.) stau in `inventory/hosts.yaml`;

-- `generated/j1.conf` si `generated/j2.conf` mostenesc blocul global company-managed

-  si omit `User`/`Port` cand toate aliasurile unui host sunt deja acoperite de

-  regulile `Match Host` de pe jump;

-- `generated/j1.conf` si `generated/j2.conf` nu mai includ hosturile care folosesc

-  doar defaulturi mostenite; raman doar override-urile efective si exceptiile

-  per-pattern care trebuie pastrate pe jump;

-- `generated/j1.conf` si `generated/j2.conf` sunt generate fara comentarii,

-  doar cu stanza-urile SSH necesare;

-- hosturile Radius folosesc acelasi flux nested prin J1 ca restul hosturilor finale.

-

-Aliasuri principale:

-

-| Alias | Rol | Rutare |

-| --- | --- | --- |

-| `is-jumper` | VPN gateway + gardian cheie fizica | direct (IP 192.168.2.100) |

-| `J1`, `J2` | jump hosts, login interactiv | wrapper prin is-jumper |

-| `voip-prov`, `voip-prov-root` | host VoIP provider | wrapper nested prin J1 |

-| `porta-sip`, `porta-web`, `porta-db`, `porta-configurator` | PortaOne MR30 | wrapper nested prin J1 |

-| `elastix` | host vechi | wrapper nested prin J1 |

-| `*.radius-db`, `*.radius-pppoe` | baze Radius regionale | wrapper nested prin J1 |

-

-`J1` si `J2` nu mai folosesc `ProxyJump`, `IdentityAgent` sau `RemoteCommand` in configul local; wrapper-ul orchestreaza explicit conexiunea prin `is-jumper`.

-

-## PortaOne

-

-Aliasuri PortaOne:

-

-- `porta-sip`, `p12-sip`, `p12`, `p12.voip.ro` -> `193.16.148.4`

-- `porta-web`, `porta-api`, `porta-slave`, `porta7`, `telefonie.next-gen.ro` -> `193.16.148.7`

-- `porta-db`, `porta-master`, `porta1` -> `193.16.148.11`

-- `porta-configurator`, `porta-config` -> `193.16.148.13`

-

-Aceste hosturi folosesc ruta nested din wrapper; eventualele optiuni de compatibilitate ale hop-ului final sunt asigurate pe `J1`/`J2`.

-

-## Verificari

-

-Verificare configuratie fara conectare:

-

-```bash

-ssh -G is-jumper | grep -E '^(hostname|user|identityfile|identitiesonly)'

-ssh -G porta-db | grep -E '^(hostname|user|port)'

-ssh -G falticeni.radius-db | grep -E '^(hostname|user|port|connecttimeout)'

-```

-

-Verificare read-only cu conectare:

-

-```bash

-ssh porta-db hostname

-ssh porta-sip 'service porta-sip status'

-ssh voip-prov hostname

-scp porta-db:/etc/hosts /tmp/test-scp

-sftp porta-db <<< 'ls /'

-```

-

-## Mentenanta

-

-- Cand adaugi o cheie noua, pune-o in `~/.ssh/keys` si seteaza permisiuni `600` pentru cheia privata.

-- Cand adaugi un host nou: adauga-l in `inventory/hosts.yaml`, ruleaza generatorul si apoi `tools/deploy-local.sh`.

-- Cand adaugi un domeniu nou: adauga un grup nou in `inventory/hosts.yaml`.

-- Cand adaugi un wrapper nou: adauga scriptul in `scripts/` in repo si lasa `tools/deploy-local.sh` sa il instaleze in `~/.local/bin/`.

-- Nu readuce `ProxyJump`, `IdentityAgent /tmp/is-jumper-agent.sock`, helperul Python sau port-forwarding per-host.

-- Nu activa `ForwardAgent yes` pe hosturile finale fara un motiv explicit.

-- Dupa modificari la wrappers sau config, verifica: `ssh -G <alias>` si cel putin un alias read-only (`ssh porta-db hostname`).

-# SSH Keys and Access Guide

-

-Centralized reference for SSH key management and access paths.

-

-## Key Storage

-

-### Local Keys (on your machine)

-

-```

-~/.ssh/keys/

-  id_ed25519           → ~/.ssh/id_ed25519 (modern, preferred)

-  id_ed25519_2026-05

-  id_ed25519_2026-05.pub

-  id_rsa               (RSA legacy, 2048-bit)

-  id_rsa_old           (deprecated, from 2015)

-  id_rsa_old.pub

-  is-jumper_ed25519    (specific to is-jumper entry point)

-  is-jumper_ed25519.pub

-```

-

-### Physical Hardware Key (on is-jumper)

-

-**⚠️ IMPORTANT**: The primary authentication for the **company network (J1/J2)** is a **physical hardware security key (card/smartcard)** mounted **only on is-jumper** (192.168.2.100).

-

-- **Location**: is-jumper (192.168.2.100) only

-- **Type**: Hardware security module / smartcard (RSA 4096-bit)

-- **Exposed via**: GPG agent at `/run/user/0/gnupg/S.gpg-agent.ssh` (on is-jumper)

-- **Access method**: SSH agent forwarding through is-jumper

-- **Users served**: Multiple users from the 192.168.2.0/24 network

-

-**You cannot access J1/J2 directly from your local machine.** The connection must go through is-jumper, which holds the only valid physical key for the company network.

-

-## Key Usage Matrix

-

-| Key | Location | Used By | Purpose | Auth Method |

-| --- | --- | --- | --- | --- |

-| **Physical card (RSA 4096)** | Hardware on is-jumper only | J1, J2, company network | Primary auth for nextgen network | Hardware smartcard via GPG agent |

-| **is-jumper ED25519** | `~/.ssh/keys/is-jumper_ed25519` | Your machine → is-jumper | Access the entry point | pubkey + IdentitiesOnly |

-| **Modern ED25519** | `~/.ssh/id_ed25519` | Local lab, final hosts | Secondary/fallback auth | pubkey |

-| **Legacy RSA** | `~/.ssh/id_rsa` | Legacy systems | Transitional | pubkey |

-| **Deprecated RSA** | `~/.ssh/keys/id_rsa_old` | Very old hosts | Final fallback | pubkey |

-

-**Key insight**: You authenticate TO is-jumper with your local ED25519 key, but once on is-jumper, the system uses the **physical hardware key** to authenticate to the company network (J1/J2).

-

-## Access Paths and Routing

-

-### 1. Local Lab Setup (192.168.2.0/24)

-

-**Direct access** — no jump needed:

-

-```

-is-jumper (192.168.2.100)

-├─ User: root

-├─ Port: 22

-├─ Key: ~/.ssh/keys/is-jumper_ed25519

-├─ IdentitiesOnly: yes

-└─ Routing: SSH_ROUTE=local

-

-Local dev machines (192.168.2.110-122)

-├─ User: bogdan

-├─ Port: 22

-└─ Key: ~/.ssh/id_ed25519

-```

-

-Access to is-jumper:

-

-```bash

-# Direct connection (SSH will use is-jumper_ed25519 via IdentitiesOnly)

-ssh is-jumper

-

-# Verify key in use:

-ssh -G is-jumper | grep identityfile

-```

-

-### 2. Production: Via is-jumper → J1/J2 → Final Hosts

-

-**Access chain for internal company network (10.253.51.0/24)**:

-

-```

-Your machine (local)

-  ↓ (ED25519 pubkey)

-is-jumper (192.168.2.100) [VPN client + physical card key guardian]

-  ↓ (SSH agent forwarding + physical card RSA 4096)

-J1 (10.253.51.50:25904) or J2 (10.253.51.52:25904) [jump hosts]

-  ↓ (SSH forward)

-Final host (voip, porta, radius, etc.)

-```

-

-**Critical**: You cannot connect to J1/J2 directly from your local machine because the physical hardware key is **only on is-jumper**. All company network access must go through is-jumper first.

-

-#### Step 1: is-jumper (entry point)

-

-Authenticate to is-jumper with your local ED25519 key:

-

-- **User**: root

-- **Host**: 192.168.2.100

-- **Port**: 22

-- **Key**: `~/.ssh/keys/is-jumper_ed25519`

-- **IdentitiesOnly**: yes (forces use of specified key only)

-

-```bash

-ssh is-jumper

-```

-

-Once logged in, is-jumper has access to the physical card key via GPG agent at `/run/user/0/gnupg/S.gpg-agent.ssh`.

-

-#### Step 2: J1/J2 (jump hosts) — via is-jumper's physical key

-

-**SSH agent forwarding** connects your SSH client to is-jumper's physical card:

-

-- **Routing**: ProxyJump is-jumper

-- **Authentication on J1/J2**: Physical card (RSA 4096) via `SSH_AUTH_SOCK=/run/user/0/gnupg/S.gpg-agent.ssh`

-- **User on J1/J2**: `bogdan.timofte` (company network default)

-- **Port**: 25904 (VPN jump port)

-

-```bash

-ssh j1        # Routes: local → is-jumper → J1 (using is-jumper's physical key)

-ssh j2        # Routes: local → is-jumper → J2 (using is-jumper's physical key)

-```

-

-**The SSH config handles this automatically** — you don't need to manually set up agent forwarding. The wrapper or ProxyJump chain uses is-jumper's physical key to authenticate.

-

-**Verify J1 config**:

-

-```bash

-ssh -G j1 | grep -E '^(hostname|port|user|proxyjump)'

-```

-

-#### Step 3: Final Hosts

-

-**From J1/J2 to actual hosts** (configured in J1's/J2's local SSH config):

-

-- **User**: varies by host group (bogdan, bogdan.timofte, root, etc.)

-- **Port**: 22 (standard) or 24 (jump hosts default) or custom

-- **Key**: `~/.ssh/id_ed25519`

-- **ProxyJump**: j1 or j2

-

-```bash

-# Example: PortaOne database server

-ssh porta-db        # → is-jumper → J1 → 193.16.148.11

-

-# Example: VoIP PBX

-ssh voip-prov       # → is-jumper → J1 → 10.253.51.139

-

-# Example: Radius database

-ssh falticeni.radius-db  # → is-jumper → J1 → falticeni.radius-db:24

-```

-

-### 3. Emergency Public Routes (j1.next-gen.ro / j2.next-gen.ro)

-

-If internal VPN is down, use public DNS names:

-

-```bash

-# Standard (internal VPN)

-ssh j1              # 10.253.51.50:25904

-

-# Emergency (public DNS)

-ssh j1.next-gen.ro  # j1.next-gen.ro:25904

-ssh j2.next-gen.ro  # j2.next-gen.ro:25904

-```

-

-Both routes go through is-jumper first (no direct connection).

-

-## Key Migration Status

-

-### Check which hosts have modern keys

-

-```bash

-# Test all local lab hosts

-for h in is-baobab is-ebony is-tapia is-jumper is-mazeri is-toltec is-andrafiabe is-anjohibe is-nasturel is-mat; do

-  timeout 2 ssh -o BatchMode=yes "$h" true 2>/dev/null && echo "$h: ✓" || echo "$h: ⚠"

-done

-```

-

-### Migrate a host to modern ED25519 key

-

-```bash

-# Automatic migration (uses legacy key to install modern key)

-tools/migrate-modern-key.sh is-baobab

-

-# Or migrate all

-tools/migrate-modern-key.sh

-```

-

-See [docs/KEY_MIGRATION.md](docs/KEY_MIGRATION.md) for manual procedures.

-

-## SSH Config Generation

-

-The `~/.ssh/config` is **auto-generated** from inventory — do not edit manually.

-

-```bash

-# Regenerate after inventory changes

-python3 tools/generate-configs.py

-

-# Deploy to ~/.ssh/config

-cp generated/client.conf ~/.ssh/config

-# or use the deploy script:

-tools/deploy-local.sh

-```

-

-**Config files generated**:

-

-| File | Target | Purpose |

-|------|--------|---------|

-| `generated/client.conf` | local client (~/.ssh/config) | local access config |

-| `generated/is-jumper.conf` | is-jumper (via deploy) | is-jumper alias config |

-| `generated/j1.conf` | J1 (server-side) | final host access on J1 |

-| `generated/j2.conf` | J2 (server-side) | final host access on J2 |

-

-## Troubleshooting

-

-### "Permission denied (publickey)" on J1/J2

-

-**⚠️ First check**: Do you have **access to is-jumper**?

-

-```bash

-ssh is-jumper "echo access ok"

-```

-

-If this fails, the issue is your local ED25519 key or is-jumper authentication. Fix that first.

-

-**If is-jumper works but J1 fails**:

-

-The issue is likely the **physical card key is not properly exposed** or **SSH agent forwarding isn't working**.

-

-**Diagnosis**:

-

-```bash

-# 1. Check if you can reach is-jumper

-ssh is-jumper

-

-# 2. From is-jumper, verify the physical card is available

-ssh is-jumper "ls -la /run/user/0/gnupg/S.gpg-agent.ssh"

-# Should exist and be readable

-

-# 3. Check J1 connectivity with verbose output

-ssh -vvv j1 2>&1 | grep -E "ProxyJump|Offering|Authentications|Trying"

-```

-

-**Solutions**:

-

-1. **is-jumper's SSH agent not running**:

-   ```bash

-   ssh is-jumper "ps aux | grep gpg-agent"

-   # If not running, restart it or contact the system administrator

-   ```

-

-2. **SSH config not set up for agent forwarding**:

-   - Verify ProxyJump is configured: `ssh -G j1 | grep proxyjump`

-   - Verify `ForwardAgent yes` is set (check generated config)

-

-3. **Physical card key not accessible**:

-   - This is a system issue on is-jumper — contact the key administrator

-   - The card may need to be re-mounted or re-authenticated

-

-4. **SSH on your machine not supporting agent forwarding**:

-   ```bash

-   # Ensure SSH_AUTH_SOCK is set when you SSH to is-jumper

-   ssh -A is-jumper

-   ```

-

-### "Permission denied (publickey)" on is-jumper

-

-**The issue**: Your local ED25519 key isn't authorized on is-jumper.

-

-**Verify your key is present**:

-

-```bash

-ls -la ~/.ssh/keys/is-jumper_ed25519

-cat ~/.ssh/keys/is-jumper_ed25519.pub

-```

-

-**Check that is-jumper has your key**:

-

-```bash

-ssh is-jumper "cat ~/.ssh/authorized_keys | grep -i ed25519"

-```

-

-If your key isn't there, it needs to be added by the is-jumper administrator.

-

-### "No route to host" (10.253.51.x)

-

-**Cause**: Trying to reach J1/J2 directly without going through is-jumper.

-

-**Check ProxyJump**:

-

-```bash

-ssh -G j1 | grep proxyjump

-# Must show: proxyjump is-jumper

-```

-

-If not, regenerate config: `python3 tools/generate-configs.py && cp generated/client.conf ~/.ssh/config`

-

-### SSH hangs or timeouts

-

-**For jump hosts** (reduce to 5-10 seconds):

-

-```bash

-ssh -o ConnectTimeout=5 is-jumper

-ssh -o ConnectTimeout=5 j1

-```

-

-**Check network**:

-

-```bash

-# is-jumper reachable?

-ping 192.168.2.100

-

-# If behind firewall, may need port 22 open to is-jumper

-```

-

-## Maintenance Checklist

-

-- [ ] Keep both `id_ed25519` and `id_rsa_old` until all hosts migrated

-- [ ] After adding new hosts: run `tools/migrate-modern-key.sh <host>`

-- [ ] After inventory changes: regenerate with `python3 tools/generate-configs.py`

-- [ ] Periodically check: `ssh -G <alias>` to verify config without connecting

-- [ ] Never manually edit `~/.ssh/config` — it's auto-generated

-- [ ] Keep keys in `~/.ssh/keys/` with mode `600`

-

-## References

-

-- [Ed25519 vs RSA Security](https://ianix.com/pub/ed25519-deployment.html)

-- [OpenSSH Manual](https://man.openbsd.org/ssh)

-- [Project inventory structure](inventory/hosts.yaml)

-- [Key migration procedures](docs/KEY_MIGRATION.md)

-- [Architecture details](ARCHITECTURE.md) (legacy Romanian docs: `.doc/ssh-jump-architecture.md`)

-# SSH Infrastructure

-Source-controlled SSH routing and configuration for multi-user jump infrastructure

-(`is-jumper` gateway → J1/J2 company network → final hosts).

-**⚠️ New to this project?** Start with [KEYS_AND_ACCESS.md](KEYS_AND_ACCESS.md) — it

-explains which SSH key to use where, and how the access chain works.

-## Quick Start

-# 1. Access the local jump gateway

-ssh is-jumper

-# 2. From there, reach company network via J1 or J2

-ssh j1              # or: ssh j2

-# 3. From J1, reach final hosts

-ssh porta-db        # automatic routing: local → is-jumper → J1 → porta-db

-The `~/.ssh/config` is auto-generated from `inventory/hosts.yaml` — edit the

-inventory, not the config file.

-## File Structure

-- **Project source**: `~/Documents/Workspaces/Bogdan/ssh-infrastructure`

-- **OpenSSH runtime**: `~/.ssh` (do not commit)

-Keep secrets and machine-local state out of version control:

-- private keys: `~/.ssh/keys/` (not in git)

-- `authorized_keys`, `known_hosts`, socket state (not in git)

-Deploy the local runtime with:

-# Regenerate ~/.ssh/config from inventory + install wrappers

-## Version control

-This directory is the git repository for source files only. Generated configs,

-local state, keys, known hosts, and handoff notes stay out of version control.

-Track source changes with:

-git status

-git add inventory schema scripts tools .doc README.md .gitignore

-git commit

-## SSH Key Management

-Which key goes where? See [KEYS_AND_ACCESS.md](KEYS_AND_ACCESS.md) for the full matrix.

-Migrate hosts from legacy RSA to modern ED25519:

-# Migrate all legacy hosts

-# Migrate a specific host

-Details: [docs/KEY_MIGRATION.md](docs/KEY_MIGRATION.md)

-## Current client layout

-~/.ssh/config

-~/.local/bin/ssh

-~/.local/bin/scp

-~/.local/bin/sftp

-The wrapper sources stay versioned in `scripts/` inside the project; deploy

-installs executable copies into `~/.local/bin` and removes the obsolete

-`~/.ssh/scripts` runtime layout from older checkouts.

-## Source of Truth

-The structured source of truth starts in:

-inventory/hosts.yaml

-schema/hosts.schema.json

-tools/generate-configs.py

-The `generated/*.conf` files are deploy artifacts. They are ignored by git and

-can be recreated at any time with `tools/deploy-local.sh`.

-## Inventory and Config Generation

-The single source of truth:

-inventory/hosts.yaml         ← edit here to add/modify hosts

-  ↓ (python3 tools/generate-configs.py)

-generated/client.conf        ← deployed to ~/.ssh/config

-generated/is-jumper.conf     ← deployed to is-jumper

-generated/j1.conf            ← deployed to J1

-generated/j2.conf            ← deployed to J2

-### User and Port Defaults

-| Context | User | Port | Notes |

-| --- | --- | --- | --- |

-| Jump hosts (J1, J2) | `bogdan.timofte` | `24` (standard) or `25904` (VPN) | override in inventory |

-| Final hosts | `bogdan` | `22` | most systems; dotted usernames cause issues |

-| Interactive auth (Cisco, OLTs) | varies | `22` | marked with `auth: password_interactive` |

-### Deployment

-# Option 1: Full deploy (recommended)

-# Option 2: Manual steps

-python3 tools/generate-configs.py           # Regenerate configs

-cp generated/client.conf ~/.ssh/config      # Install client config

-### Sync from Upstream

-Pull latest `hosts.yaml` from nextgen and redeploy:

-tools/sync-hosts-from-upstream.sh

-# Customize:

-DEPLOY_AFTER_SYNC=0 tools/sync-hosts-from-upstream.sh  # generate only

-UPSTREAM_SSH_TARGET=user@host tools/sync-hosts-from-upstream.sh  # custom source

-# SSH Key Migration: Legacy to Modern

-

-## Overview

-

-This document describes the process for migrating hosts from legacy SSH keys (`id_rsa_old`) to modern keys (`id_ed25519`).

-

-## Rationale

-

-- **Legacy key** (`id_rsa_old` from 2015): RSA 2048-bit, older algorithm support

-- **Modern key** (`id_ed25519`): EdDSA 256-bit, better security, smaller key size, faster

-

-## Automatic Migration

-

-### Migrate all legacy hosts

-

-```bash

-tools/migrate-modern-key.sh

-```

-

-This will:

-1. Check all hosts in `inventory/hosts-local.yaml` legacy_infrastructure group

-2. Test if modern key already works

-3. Use legacy key to install modern key if needed

-4. Verify modern key works after installation

-

-### Migrate specific host

-

-```bash

-tools/migrate-modern-key.sh is-baobab

-```

-

-## Manual Migration (if script fails)

-

-For a specific host, e.g., `is-nasturel`:

-

-### 1. Interactive password auth

-

-If password is available:

-

-```bash

-ssh -o PubkeyAuthentication=no sshd@192.168.2.144 \

-  "mkdir -p ~/.ssh && \

-   echo '$(cat ~/.ssh/id_ed25519.pub)' >> ~/.ssh/authorized_keys && \

-   chmod 600 ~/.ssh/authorized_keys"

-```

-

-### 2. Through jump host (is-jumper)

-

-If accessible through is-jumper:

-

-```bash

-ssh is-jumper \

-  "ssh -o StrictHostKeyChecking=accept-new sshd@192.168.2.144 \

-    'mkdir -p ~/.ssh && echo \$(cat ~/.ssh/id_ed25519.pub) >> ~/.ssh/authorized_keys'"

-```

-

-### 3. Physical/console access

-

-If all else fails, use console/IPMI access to manually:

-- Edit `/home/sshd/.ssh/authorized_keys`

-- Add modern key: `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...`

-

-## Adding New Hosts

-

-When adding new legacy hosts to the inventory:

-

-1. **In `inventory/hosts-local.yaml`**: add host to `legacy_infrastructure` group

-2. **Run deployment**: `tools/deploy-local.sh`

-3. **Run migration**: `tools/migrate-modern-key.sh <new-host>`

-4. **Commit**: `git add . && git commit -m "Add/migrate <host>"`

-

-## Status Tracking

-

-Check which hosts have been migrated:

-

-```bash

-# Modern key working

-for h in $(grep -oE "is-[a-z0-9-]+" inventory/hosts-local.yaml | sort -u); do

-  timeout 1 ssh -o BatchMode=yes "$h" true 2>/dev/null && echo "$h: ✓" || echo "$h: ⚠"

-done

-```

-

-## Key Files

-

-- **Modern (preferred)**: `~/.ssh/id_ed25519`

-- **Legacy (deprecated)**: `~/.ssh/keys/id_rsa_old`

-

-Both should be kept until all hosts are migrated.

-

-## Removing Legacy Key

-

-Once all hosts migrated and verified:

-

-```bash

-# Backup first

-cp ~/.ssh/keys/id_rsa_old ~/.ssh/keys/id_rsa_old.backup

-

-# Remove from SSH config (if any explicit config)

-grep -r "id_rsa_old" . && echo "Still in use" || echo "Safe to remove"

-

-# Safe to delete after backup

-rm ~/.ssh/keys/id_rsa_old

-```

-

-## Troubleshooting

-

-### "Permission denied (publickey)" with modern key

-

-→ Host still using legacy auth only. Use `tools/migrate-modern-key.sh <host>`

-

-### Legacy key also fails to connect

-

-→ Host might be offline or firewall blocked. Check connectivity first:

-

-```bash

-ping 192.168.2.91  # Replace with host IP

-```

-

-### SSH hangs or times out

-

-→ Reduce timeout, check firewall rules. Use `-o ConnectTimeout=2` flag.

-

-## References

-

-- [Ed25519 SSH keys - OpenSSH](https://man.openbsd.org/ssh-keygen)

-- [Why Ed25519 is superior to RSA](https://ianix.com/pub/ed25519-deployment.html)