fix(gluekube_ssh): use ProxyJump instead of SSH agent forwarding

[venkatamutyala]

Problem

gluekube_ssh --profile <p> --cluster <fqdn> --kubectl (and the interactive SSH / kubeconfig / port-forward paths) fail with:

✗ Failed to fetch kubeconfig - aborting (existing ~/.kube/config left untouched)

Root cause is not the AutoGlue API — cluster resolution, /clusters/<id>, and /ssh/<id>?reveal=true all return correct data. The bastion's sshd has been hardened to:

allowagentforwarding no
allowtcpforwarding yes

Every bastion hop in the script used ssh -A + a nested ssh on the bastion and relied on the forwarded agent to authenticate the second hop. With agent forwarding disabled, the forwarded agent is stripped and the master rejects the connection: Permission denied (publickey).

Fix

Reach cluster nodes through the bastion with a -W ProxyCommand instead of agent forwarding. Both hops authenticate from the local ssh-agent (keys are already loaded by load_connection_keys):

• The agent is never forwarded to the bastion → works with AllowAgentForwarding no.
• No private key is ever written to disk → more secure than agent forwarding, and avoids key-at-rest exposure.
• Only needs AllowTcpForwarding yes, which is enabled.

Converted call sites: headless quick-connect fetch + port-forward (kubeconfig_and_port_forward), interactive port-forward (kubectl_mode), kubeconfig copy (kubeconfig_mode), and non-bastion SSH (connect_ssh). Added a shared bastion_proxy helper + SSH_OPTS.

Because the tunnel now terminates on the master, the port-forwards bind 6443 locally only — nothing on the bastion — so the random mid-port workaround (previously needed to dodge a stale bastion-side 6443 bind) is removed.

Testing

Verified end-to-end against nonprod.jupiter.onglueops.rocks:

• Fresh kubeconfig fetched and saved.
• Foreground port-forward established; kubectl get --raw=/version through the tunnel returned v1.34.5.
• bash -n syntax check passes.

🤖 Generated with Claude Code