Closed bml1g12 closed 1 year ago
@bml1g12 technically this repository is for a different component than the one you seem to be having a problem with. You seem to be using the official SecureTunneling component in version 1.0.9.
This repository describes an alternative approach using the aws-iot-device-client and a Python application packaged into a container image. Using a container image allows you to customize and tailor the device client independent from the host operating system and therefore avoid issues with incompatibilities between Linux distributions or library dependencies.
/cc @HarshGandhi-AWS for visibility on the re:port thread.
Hi @bml1g12,
I think this might actually be an issue with the log output. Those error logs don't appear to be error logs... The logs have both [INFO] and [ERROR] and it may be that the GreenGrass SecureTunneling Component is outputting the logs incorrectly here... I will take a look into that.
But I think that it may actually be working here. If you check the status of the tunnel either with the describe-tunnel API or through the console, is the destination CONNECTED?
I do not believe the file permissions on /tmp/ is fatal.
The component is looking for the path to the RootCA in that dummy config file that is passed to it... and then defaulting to the default trust store. That shouldn't be a problem either.
"It looks to me like it is crashing because it is defaulting to some template config file"
Is it actually crashing? If not I think it might actually be working and this is a logging issue.
[2022-11-08T16:26:32.049196]{11}[error] Proxy server rejected web socket upgrade request: (HTTP/1.1 400 Bad Request) "The client access token and local-proxy-mode are mismatched"
I think you may be attempting to use the destination access token instead of the source access token.
Thank you for your swift responses!
@bml1g12 technically this repository is for a different component than the one you seem to be having a problem with. You seem to be using the official SecureTunneling component in version 1.0.9.
Sorry about that - unfortunately the component has no repo associated so this is the closest match I think.
I think you may be attempting to use the destination access token instead of the source access token.
Oh dear me, thank you so much - I'm embarrassed to say this was a human error on my part, and using the correct token it resolves the issue.
As you say, however, it does seem to indicate some logging bugs:
"key": "replace_with_private_key_file_location"
these look odd even for an info logGiven those are not related to my issue, I'll close this ticket. Thank you very much for your support.
When a tunnel is opened, the Secure Tunnelling Component throws many error logs, but I am unclear what the issue is. Much appreciated if you are able to provide any support on this, as it seems like a bug.
This seems to be the same as this unresolved issue.
I am using the following setup:
How I installed the Secure Tunneling Greengrass Component:
When deploying the component, setting the OS_DIST_INFO as raspberry this issue, resulted in an error
Cannot find file: aws.greengrass.SecureTunneling/linux/aarch64/raspberrypi/aws-iot-device
so I usedInstead (which actually I think is also what OS_DIST_INFO="auto" obtains in this particular OS).
Details of the Issue:
This results in a component that is RUNNING state, but when we open a tunnel (
aws iotsecuretunneling open-tunnel --region ap-northeast-1 --destination-config thingName=${THING_NAME},services=SSH
) I get the following in/greengrass/v2/logs/aws.greengrass.SecureTunneling.log
And in the IoT Client I get the following:
Some questions that come to mind:
What I've tried