better sshconfig control

[0xtavian]

Previously, running multiple aixom-scans in the background without --cache would cause errors, such as: clearing selected.conf ( instances would no longer be selected ), prompts for password and Permission Denied (publickey), these errors were sometimes imperceptible and no user interaction was required to continue the scan. this was because we used non-interactive ssh sessions for execution. Now that we use fully PTY ( for tmux etc ), these errors cant be easily ignored anymore as some require some level of user input ( y/n to update Oh My Zsh etc on login ), AFAIK.

Why this happened: Previous to this patch, when the second scan was executed, assestfinder in this case, the first command ( subfinder) would still be generating its axiom SSH config ( if --cache isnt used ), and since it copies the current ssh config into a location $AXIOM_PATH/.sshconfig.new, axiom would overwrite and mangle the same file in parallel, causing all sorts of different malformed sshconfigs ( hints why so many different errors ). Now $AXIOM_PATH/.sshconfig.new is $AXIOM_PATH/.sshconfig.new$RANDOM, which prevents these types of issues. Both of these examples now run without issue.

axiom-scan subs -m subfinder &
axiom-scan subs -m assetfinder &
axiom-scan subs -m amass &

The previous workaround to this was running all subsequent axiom-scans with --cache ( shown below), this is no longer needed.

axiom-scan subs -m subfinder &
axiom-scan subs -m assetfinder --cache &
axiom-scan subs -m amass --cache & 

Additionally, the generate_sshconfig function is called earlier in axiom-scan, making for a more reliable generation.

[pry0cc]

Hehe I like this. Smart. A few considerations:

• $RANDOM only produces a 5 digit number, so it is possible that you get lucky one day and $RANDOM is the same twice.

May I suggest we attempt to resolve this with a lock file instead? It feels slightly wasteful to look up new instances every time if were launching several scans simultaneously.

[0xtavian]

Hey @pry0cc! Thanks!

And yea I agree we make a few extra calls to generate_sshconfig than absolutely required ( but what else is new :p ). I try to encourage people with automation to use —cache but sometimes it’s not desirable.

Can you give me an example of how you could resolve this with a lock file instead? running axiom-ssh —just-generate lock will permanently lock the sshconfig for all commands until you revert with axiom-ssh —just-generate or axiom-ssh —just-generate public.

I’ve slowly been getting rid of superfluous calls to list droplets but we could do better.

Can you explain your thought process behind the lock file? Keep in mind the way it is now, ya we make a few extra calls but it a lot less error prone imo. we should be able to run axiom-fleet ( or spinup ) and axiom-rm ( or rm when done) at any time during someone’s automation workflow ( mid workflow for example). That wouldn’t be possible if we lock and prevent the sshconfig from generating, unless im missing something.

Plus if we lock it and have some workflow running in the background, we wouldn’t be able to init/fleet ( on another terminal for example), so axiom sshconfig generation would be basically stuck while the automation is running?

And probably the most important part, how would we know when to lock the file?