First decide if you want to daisy-chain sshs or you want "nested tubes" ssh -J gives you. Read this answer of mine to see what I mean. You tried both and it's not clear which one you want. In general ssh -J is better (e.g. port forwarding or allocating a tty is simpler than in the daisy-chain case).
If you want
ssh -J(I recommend this) then only keys available to your localsshwill matter. No SSH client will be invoked on the jump host. Your private keys (if any) stored on jump host will be irrelevant, so the fact you cannot runssh-keygenthere to create them does not matter; they would be of no use anyway. Your local identity can be used to authenticate you on the jump host and on the target server. I assume you have runssh-keygenlocally. First register your key on the jump host by running the following command locally:ssh-copy-id username@JumpServerThen use the jump host to connect to the target server and register your key there. Run this locally:
ssh-copy-id -o ProxyJump=username@JumpServer username@targetServerNote
ssh -J …is a shortcut to specifyssh -o ProxyJump=…, but sincessh-copy-iddoes not support-J, we had to use the other syntax here.Now, if both servers are configured to allow key-based authentication then you will be able to
ssh -J username@JumpServer username@targetServerfrom your local machine.If you want to daisy-chain
sshs then it's reasonable to have a private key on the jump host and use it to authenticate whensshing to the target server. I understand you cannot runssh-keygenon the jump host. You can still create a key locally, register it on the target server and move (or copy) the keypair to the jump host, so the files will be there as if you had created them there withssh-keygen.
In general each SSH server may be configured to disallow certain things and this may limit your options or impose certain actions. E.g. if you have managed to make the jump host accept your key, but the target server asks for password no matter what, then this local command will be handy:
sshpass -p'myPassword' ssh -J username@JumpServer username@TargetServer(This idea has already been posted in a comment.)
Notes:
sshpass -f…should be preferred oversshpass -p….- The server may use a custom prompt for password, so maybe you need to tell
sshpasswhat prompt to expect (example).