Open gprime31 opened 2 years ago
burp settings.
get this on shutdown.
also tried: curl --socks5-hostname 192.168.1.18:1337 https://ipinfo.io/ | jq ( cause of 0.0.0.0:1337) from local maching and tried from another machine on the same network, same error.
We have issues with axiom-proxy. It currently does not work out of the box. I planned on trying to implement the same with Proxify, but haven’t had the time. https://github.com/pry0cc/axiom/issues/498
Yesterday I could make axiom-proxy
work for me by seting up ssh keys with ssh-copy-id
. I configured one running instance with the keys, ran axiom-backup
on that machine and deployed a new fleet with the new image.
testing with curl http://ipecho.net/plain -L --proxy localhost:1337
worked fine then
edit: typo
... Christ :0
Switch default images? Yes, I never edit axiom.json
Every time I run axiom-backup
I then run axiom-images
to see and configure the default image that will be used for every new instance.
Example:
axiom-images # help page
axiom-images ls
axiom-images set axiom-nyc2-11223344
I want to add that it seems that if use axiom-images use {id}
it will set up the image for when running axiom-init
, and using axiom-images set {id}
will set the image to use when running axiom-fleet
(the difference is the use/set keyword), I haven't tested this.
Thanks :) got it down to a 5 min setup (not including the build and backup time). i didn't use ssh-copy-id, kept asking for a password? but it's fine, I just used wget and merged the public file in. now both ways work to ssh. Works great!
... Christ :0
Switch default images? Yes, I never edit
axiom.json
axiom.json is just a symbolic link to $HOME/.axiom/accounts/{your-selected-account}.json
. You can technically edit it if the account is selected. I do the same as you, use axiom images get/set for setting images.
Every time I run
axiom-backup
I then runaxiom-images
to see and configure the default image that will be used for every new instance.
that’s awesome that you use axiom-backup. Its so convenient and one of the lesser known features. I plan to refactor it sooner or later. I need to move the functions into do-functions.sh ( for example) and port it to azure. Other than that it works great. ( I’ll add DO’s —wait
as an option as well.
I want to add that it seems that if use
axiom-images use {id}
it will set up the image for when runningaxiom-init
, and usingaxiom-images set {id}
will set the image to use when runningaxiom-fleet
(the difference is the use/set keyword), I haven't tested this.
I wish! That sounds awesome lol. But nah currently use/set do the exact same thing. But your idea will probably be in the next release of axiom-images :)
Your fix is helpful in debugging the issue thanks. Just be careful to not backup an axiom instance with hard coded cloud keys with you plan use them as proxies. You should be able to delete the API keys before backing up in case you are.
@0xtavian
get this on shutdown.
So after some more messing around, this is really a simple fix. No need to change or rewrite axiom-proxy. When the image is first created, make the script (axiom-configure) do the following: 1) ssh-keygen -t rsa ( on the machine you run axiom-configure from) 2) cat ~/.ssh/id_rsa.pub > ~/.axiom/configs/authorized_keys ( on the machine you run axiom-configure from) 3) copy ~/.ssh/id_rsa.pub to the new image (default) 4) cat id_rsa.pub >> authorized_keys (in the new image) (default) 5) axiom-backup. (not sure step 2 is required) then both ways of ssh will work and it won't mess with the original way it sets up ssh.
commands ran:
axiom-fleet burp -i 5 axiom-select 'burp' axiom-proxy 'burp' --single says [*] Started SOCKS5 Listener on '0.0.0.0:1337'... CTRL+C TO EXIT...
then: curl --socks5-hostname 127.0.0.1:1337 https://ipinfo.io | jq and curl: (7) Unable to receive initial SOCKS5 response.
what am i doing wrong?