Tinkerwell на удаленном хосте с помощью ProxyCommand? JumpHost ssh

Question

Попытка заставить Tinkerwell (для разработки Laravel и общего PHP) подключиться к удаленному хосту, который подключен только к использованию ProxyCommand.

Наши удаленные серверы разработки используют Coder.com, который использует интерфейс командной строки для записи набора записей в ваш файл ~/.ssh/config. У каждой рабочей области нет установленного IP-адреса, и он меняется каждый раз при загрузке, поскольку он находится на K8 в GKE. Ниже показано, что он добавляет в мою конфигурацию ssh, где имя рабочей области заменено на «пример».

      Host coder.example
        HostName coder.example
        ProxyCommand /Users/xan/./coder tunnel example 12213 stdio
        StrictHostKeyChecking no
        ConnectTimeout=0
        IdentitiesOnly yes
        IdentityFile="/Users/xan/.ssh/coder_enterprise"
        ControlMaster auto
        ControlPath ~/.ssh/.connection-coder.e2e2f398d4bf1e82cf846f4d30b10c48
        ControlPersist 600

VS Code отлично справляется с этим соединением. coderCLI имеет команду, котораяcoder tunnel [workspace] [remote port] [local port]и вы можете видеть в разделе «ProxyCommand» конфигурации ssh, что он использует эту команду для «stdio», чтобы разрешить ssh-соединение черезssh coder.example

Теперь Tinkerwell упоминает, что они не поддерживают автоматически ProxyJump или ProxyCommand и не используют JumpHost. Каждый способ, которым я пытался настроить это, не имел никакого значения, и я не уверен, что это произойдет, потому что на самом деле это моя машина, через которую я подключаюсь. Источник: https://tinkerwell.app/blog/using-proxyjump-to-connect-to-a-remote-host-behind-a-firewall

Если я буду следовать статье и попытаюсь подключиться к порту 22, в терминале появится сообщение об отказе в подключении, когда я нажму «Подключиться к Tinkerwell». Я думаю, это потому, что Coder использует порт 12213, как вы можете видеть в ProxyCommand в конфигурации ssh.

Если я попытаюсьssh -NL 2222:localhost:12213 coder.exampleна самом деле он довольно долго крутится, а не сразу выдает ошибку, как если бы он наконец-то соединился. Но потом выдает следующую ошибку:

      Error: Timed out while waiting for handshake
DEBUG: Local ident: 'SSH-2.0-ssh2js0.4.10'
DEBUG: Client: Trying localhost on port 2222 ...
DEBUG: Client: Connected
DEBUG: Parser: IN_INIT
DEBUG: Parser: IN_GREETING
DEBUG: Parser: IN_HEADER
DEBUG: Remote ident: 'SSH-2.0-0.0.1'
DEBUG: Outgoing: Writing KEXINIT
DEBUG: Parser: IN_PACKETBEFORE (expecting 8)
DEBUG: Parser: IN_PACKET
DEBUG: Parser: pktLen:524,padLen:19,remainLen:520
DEBUG: Parser: IN_PACKETDATA
DEBUG: Parser: IN_PACKETDATAAFTER, packet: KEXINIT
DEBUG: Comparing KEXINITs ...
DEBUG: (local) KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
DEBUG: (remote) KEX algorithms: [e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1
DEBUG: KEX algorithm: ecdh-sha2-nistp256
DEBUG: (local) Host key formats: ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
DEBUG: (remote) Host key formats: ecdsa-sha2-nistp256
DEBUG: Host key format: ecdsa-sha2-nistp256
DEBUG: (local) Client->Server ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,[e-mail],aes256-gcm,[e-mail],aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc,arcfour256,arcfour128,cast128-cbc,arcfour
DEBUG: (remote) Client->Server ciphers: [e-mail],[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
DEBUG: Client->Server Cipher: aes128-ctr
DEBUG: (local) Server->Client ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,[e-mail],aes256-gcm,[e-mail],aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc,arcfour256,arcfour128,cast128-cbc,arcfour
DEBUG: (remote) Server->Client ciphers: [e-mail],[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
DEBUG: Server->Client Cipher: aes128-ctr
DEBUG: (local) Client->Server HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5,hmac-sha2-256-96,hmac-sha2-512-96,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
DEBUG: (remote) Client->Server HMAC algorithms: [e-mail],hmac-sha2-256,hmac-sha1,hmac-sha1-96
DEBUG: Client->Server HMAC algorithm: hmac-sha2-256
DEBUG: (local) Server->Client HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5,hmac-sha2-256-96,hmac-sha2-512-96,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
DEBUG: (remote) Server->Client HMAC algorithms: [e-mail],hmac-sha2-256,hmac-sha1,hmac-sha1-96
DEBUG: Server->Client HMAC algorithm: hmac-sha2-256
DEBUG: (local) Client->Server compression algorithms: none,[e-mail],zlib
DEBUG: (remote) Client->Server compression algorithms: none
DEBUG: Client->Server compression algorithm: none
DEBUG: (local) Server->Client compression algorithms: none,[e-mail],zlib
DEBUG: (remote) Server->Client compression algorithms: none
DEBUG: Server->Client compression algorithm: none
DEBUG: Outgoing: Writing KEXECDH_INIT
DEBUG: Parser: IN_PACKETBEFORE (expecting 8)
DEBUG: Parser: IN_PACKET
DEBUG: Parser: pktLen:300,padLen:17,remainLen:296
DEBUG: Parser: IN_PACKETDATA
DEBUG: Parser: IN_PACKETDATAAFTER, packet: KEXECDH_REPLY
DEBUG: Checking host key format
DEBUG: Checking signature format
DEBUG: Verifying host fingerprint
DEBUG: Host accepted (verified)

Не уверен, что мне чего-то не хватает, чтобы подключиться с помощью JumpHost, или что-то еще странное с SSH, чтобы заставить Tinkerwell думать, что это локально.