Try PubSub+
If you haven't already, check out our new Developer Portal! You'll find useful information about Solace PubSub+ as well as handy resources to get you started.

How to setup public ssh keys on Solace container?

TD_asilvaTD_asilva Member Posts: 10
edited March 25 in PubSub+ Software


I am trying to setup ssl on my Solace Pub/Sub+ instance on aws. The instructions say you need to use sftp or scp to transfer the certificate(s) from another machine. The only way I seem to be able to authenticate with external machines for sftp/scp is via public ssh key - but, the only ways to get a public key into the container is to copy one from outside the container or generate it inside the container - neither of which, do I seem able to do (i.e. the cli file management methods support copying files around that are already inside the container or getting them from outside via sftp/scp and there isn't one for creating an authorized_keys file that I could find, which would be the other option). This feels like a chicken and the egg problem, but I am confident that you would not leave this feature in a state like that, so I am sure I am missing something. It doesn't help that I am fairly green when it comes to dealing with certificates in general. Is there a way to transfer files from the host into the container that doesn't involve sftp/scp or to generate the public key from inside the container? Can someone point me to what I might be missing?

For what it's worth, I have tried running the copy command as "copy sftp://[email protected]/filepath ." and get the expected "Permission denied" response back. I do have the public key setup on the host machine and am able to get the file in question from the host machine using the standard sftp command - so it seems like everything else is setup properly, there just isn't a public key inside the container that the solace cli version of the copy sftp command can use.

Thank you!


  • uherbstuherbst Member, Employee Posts: 3 Solace Employee

    Hi TD_asilva,
    just to understand your question in the right way: You're looking for a way to transport files to a broker that is deployed as a docker container. Right ?
    And you have access to the host where the container is deployed ?
    Then you have multiple options:
    1. On the cli (the old fashioned command line interface), you can do scp from any other ip address outside. You have to use user/password, because you cant give your private ssh key anywhere.
    2. You can do scp/sftp from the outside to the cli (that's the same port as the "ssh to cli"-port). You have to use user/password, because the CLI cant configured to use private keys
    3. you can use "docker cp" to copy files to the docker container
    4. If you have your volumes mounted both in your container AND on the host, you just can copy files directly there.

    Have fun.

  • TD_asilvaTD_asilva Member Posts: 10
    edited March 26

    Hi Uli,

    Thank you for the response, but I am still having issues/questions. The answer to your initial question is yes, it is deployed as a container, however, I did not do any of the docker setup, I am using one of your pre-built aws ami's (version from the marketplace running on an ec2 instance. To minimize confusion for the rest of this discussion, I would like to use the following terms - the bash shell that I am using on my local laptop to do all of this will be called "dev cli", the shell of the ec2 instance/docker host will be called "ec2 cli" and the Solace-specific cli that I get when I run solacectl cli on the ec2 instance will be called "solace cli". There's also a 4th cli when you run solacectl shell on the ec2 instance - that will be called "solace shell". Also, when I mention "external", I am meaning external to aws.

    Regarding your proposed solutions, for #1, using a password for an external sftp server is not an option for me, however, even if it were, how do I specify a password when inside the solace cli and trying to copy from the external server? Everything I've found says you can only use username/password with sftp/scp by setting the password ahead of time using the sshpass tool, which is not available in the solace cli. For #2, I created a file-transfer user on the solace cli as detailed here: and then tried to transfer a file into the solace cli file system (i.e. the one shown here: using sftp/scp from the dev cli and ec2 cli, but got "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)." for both cases. For #3, I can transfer a file onto the container using docker cp, but when I do, I can only see it via the solace shell, not the solace cli - so is there a path for getting a file from the solace shell file system to the solace cli file system? For #4, I wasn't sure which volume mapped to the solace cli filesystem - I see the following volumes in the container when I do docker inspect solace:

    "Mounts": [ { "Type": "volume", "Name": "adbBackup", "Source": "/var/lib/docker/volumes/adbBackup/_data", "Destination": "/usr/sw/adb", "Driver": "local", "Mode": "z", "RW": true, "Propagation": "" }, { "Type": "volume", "Name": "internalSpool", "Source": "/var/lib/docker/volumes/internalSpool/_data", "Destination": "/usr/sw/internalSpool", "Driver": "local", "Mode": "z", "RW": true, "Propagation": "" }, { "Type": "volume", "Name": "adb", "Source": "/var/lib/docker/volumes/adb/_data", "Destination": "/usr/sw/internalSpool/softAdb", "Driver": "local", "Mode": "z", "RW": true, "Propagation": "" }, { "Type": "volume", "Name": "jail", "Source": "/var/lib/docker/volumes/jail/_data", "Destination": "/usr/sw/jail", "Driver": "local", "Mode": "z", "RW": true, "Propagation": "" }, { "Type": "volume", "Name": "var", "Source": "/var/lib/docker/volumes/var/_data", "Destination": "/usr/sw/var", "Driver": "local", "Mode": "z", "RW": true, "Propagation": "" }, { "Type": "volume", "Name": "diagnostics", "Source": "/var/lib/docker/volumes/diagnostics/_data", "Destination": "/var/lib/solace/diags", "Driver": "local", "Mode": "z", "RW": true, "Propagation": "" } ],

    Assuming maybe internalSpool, jail or var, but not sure. Thank you in advance for any further insight you can provide.

Sign In or Register to comment.