Unclean remote terminal session causes upload, download and shell modules to hang. #93
Comments
|
see #35 |
|
also new style openssh keys dont work: #53 |
|
After messing around a bit, I am able to successfully connect (at least when running a regular JVM process). However, the only command I've been able to get working with this connection is (puget/cprint (ssh {:username "..."
:hostname "..."
:port 2200
:private-key (slurp "<home>/.ssh/id_ecdsa")
:public-key (slurp "<home>/.ssh/id_ecdsa.pub")
:agent-forwarding true
:strict-host-key-checking false}
(get-fact)))Everything else I've tried will hang indefinitely after connecting. For example: (puget/cprint (ssh {:username "..."
:hostname "..."
:port 2200
:private-key (slurp "<home>/.ssh/id_ecdsa")
:public-key (slurp "<home>/.ssh/id_ecdsa.pub")
:agent-forwarding true
:strict-host-key-checking false}
(upload {:content "hello world"
:dest "/home/brain/hello.txt"})))Will hang. Output: Not sure what's going on. Do you know if there's a way to get more logs out of JSch? Also, for some reason when compiling to native I see these logged at runtime after the "CheckSignatures" line: |
|
Couple more details:
|
|
does it work under the spire binary? |
|
No, same issue with the spire binary. After trying more commands I'm it seems to be mostly file-transfer commands that fail. |
|
Very interesting. It sounds like it is not the key. For
Can you confirm that standard Also check if there are any |
|
Wow, plain |
|
You probably have an unclean session. There is something in the ssh shell startup that is echoing characters and interfering with the scp protocol. Here's some info on that. You can try the Running scp with talkative shell profiles on the remote side?People sometimes hit problems with scp while SSH connections continue to work. This is usually a problem with adding echo/printf commands to their shell profile. See two examples. scp just hangs after the password is entered when I try to copy to the remote sideFor example, this can happen if you add this to your shell profile on the remote system: Why it just hangs? That comes from the way how scp in source mode waits for the confirmation of the first protocol message. If it's not binary 0, it expects that it's a notification of a remote problem and waits for more characters to form an error message until the new line arrives. Since you didn't print another new line after the first one, your local scp just stays in a loop, blocked on scp just executes my profile and exits if I copy to the remote side...meaning that scp just prints the 1st message that is printed from user's shell profile and exits. That's because you added for example this into your shell profile: and then run the scp command: This is a very similar problem to the one already mentioned. Since the first character received wasn't binary 0 (but character 'h') it assumes a problem, reads up to the next new line character, prints that out as an error message and exits. There is an easy fix for those problems - just print what you want when you have a terminal, like this: I see protocol error: unexpected message and scp exitsAgain, similar to the 1st problem, but you are copying from the remote side. What happened? Your local scp, the data consumer, waits for the protocol message from the producer. However, it gets an empty line immediately followed by a new line character which is a violation of the protocol and your local scp then bails out. If you print more characters in your remote shell profile it is considered an error message (unless it starts with a valid protocol character in which situation the message finally printed before it fails will be even more confusing) and the whole message up to the new line character is printed and scp exits then. Example if I add And if you mess up with a valid message, for example D with printing this from your remote shell profile: Moral of this? Always check the return code of scp. |
retrogradeorbit
changed the title
|
Thanks for the detailed write up. After some investigating I'm pretty sure the issue I'm having is caused by something in the implementation of the ssh proxy backend. |
|
Theres not much I can do with an unclean terminal session so closing this. Thank's @cartesian-theatrics for reporting as it's here in the archives in case others experience it. |
Hello,
I'm having some troubles making a ssh connection. I believe it's related to using ecdsa keys, although I'm hardly an expert in ssh troubleshooting. Here's the output with --debug-ssh:
I'm setting setting the :private and :public-key fields with:
{:private-key (slurp "<home>/.ssh/id_ecdsa") :public-key (slurp "<home>/.ssh/id_ecdsa.pub")I've also tried connecting without setting :private-key and :public-key, but no luck. I am able to connect with plain ssh at the commandline no problem.
Regards,
John C.
The text was updated successfully, but these errors were encountered: