SSH with Private Key from variable file not working

[TheSecMaven]

Summary

example of normal -bash-4.2$ export test=/home/<>/.ssh/secadm_id_rsa -bash-4.2$ ssh -i $test >@< Last login: Tue Jun 23 18:43:25 2020 from <> [>@< ~]$ exit logout Connection to <> closed.

now with summon

[root@<> key_test]# summon --provider summon-conjur ssh -i $test >@< Warning: Identity file keytestuser@trooper not accessible: No such file or directory. usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname [command]

Steps to Reproduce

Steps to reproduce the behavior: secrets.yml

[root@<> key_test]# cat secrets.yml REMOTE_USER: !var AZ/Nonprod/N_A_NIX_RHL_SVC_ASEC_NL/Operating System-UnixSSHKeys-trooper.autozone.com-keytestuser/username test: !file:var AZ/Nonprod/N_A_NIX_RHL_SVC_ASEC_NL/Operating System-UnixSSHKeys-trooper.autozone.com-keytestuser/password

Expected Results

can ssh with content of that file, i see it when i do summon --provider summon-conjur env

outputs test=/dev/shm/.summon254462473

so its there, i can also see the content of that file is the private key.

Actual Results (including error logs, if applicable)

unable to ssh (command output above)

Reproducible

• [ X] Always
• [ ] Sometimes
• [ ] Non-Reproducible

Version/Tag number

[root@pr-flex001-ic01 key_test]# summon -v summon version 0.8.1

Environment setup

Linux RHEL 7

Additional Information

Add any other context about the problem here.

[BradleyBoutcher]

Hi Miclain!

Thanks for reaching out! It looks like there's some issue with the variable being passed into your ssh statement, in that it's empty. Let's try some slight syntax changes to see if it produces a different result.

I think we need to convert the variable back into a path that can be consumed by ssh -i. While summon retrieves the file as a variable from your provider, then converts that variable into a temporary local file, we need to convert that file path into a string. Testing locally, I think the following should work:

summon --provider summon-conjur \
bash -c 'export $path=$test && echo $path && ssh -i $path <>@<>'

I included the echo statement for debugging purposes. Let me know what your output looks like, and we can keep troubleshooting from there!

[TheSecMaven]

that did the trick, why is that need to be converted? can we simplify this at all? are we missing a common best practice?

[root@<> key_test]# summon --provider summon-conjur bash -c 'export path=$test && echo $path && ssh -i $path >@<' /dev/shm/.summon720073727 Last failed login: Wed Jun 24 10:40:46 CDT 2020 from <> on ssh:notty There were 16 failed login attempts since the last successful login. Last login: Wed Jun 24 10:24:53 2020 from <> [>@< ~]$

[sgnn7]

@mkkeffeler When you use summon --provider summon-conjur ssh -i $test <>@<> directly on the shell, your current (not the summon's shell) interprets the value of $test. To make sure that the variable is correctly expanded, you need to wrap ssh with something that understands env vars from summon (like bash).

You should be able to connect using this (as @BradleyBoutcher was having you test):

summon --provider summon-conjur bash -ec 'ssh -i $test <>@<>'

[sgnn7]

Given that this is probably the cause, I'll close the issue but we can continue the conversation here and/or reopen it if needed.

[TheSecMaven]

Got it, that would be a good clarification to add to the readme so people can understand that. we had been trying file descriptors and found the issue where that isn't supported so we've been messing with this for a litttle bit.

[sgnn7]

@mkkeffeler Oh that's a great idea! Would you mind opening an issue for this? I can do the same but it's better when the requirements are written by user since they add more nuance on the actual use cases.

PS: Many thanks for trying out summon! :)

[BradleyBoutcher]

Thanks for the assist @sgnn7! Glad to hear your issues was resolved @mkkeffeler, and as Srdjan said, thanks for using summon and giving us some solid feedback!