No simple way to disable auto install on remote machine

[michaelkrasa]

Checks

• [X] I have searched github.com/withfig/fig/issues and there are no duplicates of my issue
• [X] I have run fig doctor in the affected terminal session
• [X] I have run fig restart and replicated the issue again

Operating system

macOS 13.5.2 (22G91)

Expected behaviour

I expect to find a setting that enables me to change fig's default behavior on connecting to new remote hosts. I accidentally selected to always install and now don't know how to undo this.

Actual behaviour

An option either in cli or app to influence its ssh auto install behaviour.

Steps to reproduce

No response

Environment

fig-details:
  - 2.17.0
hardware-info:
  - model: 
  - model-id: 
  - chip-id: Apple M1 Max
  - cores: 10
  - mem: 32.00 GB
os-info:
  - macOS 13.5.2 (22G91)
environment:
  - shell: /bin/zsh
  - terminal: iterm
  - cwd: /Users/mkrasa
  - exe-path: /Users/mkrasa/.local/bin/fig
  - install-method: brew
  - env-vars:
    - FIGTERM_SESSION_ID: ecf61dd3-194f-4233-8abb-f0ccbda4d9bb
    - FIG_SET_PARENT_CHECK: 1
    - FIG_TERM: 2.17.0
    - PATH: /Users/mkrasa/bin:/Users/mkrasa/.local/bin:/Users/mkrasa/.local/bin:/Users/mkrasa/.rd/bin:/Users/mkrasa/bin/oracle/instantclient_19_8:/Users/mkrasa/bin/oracle/instantclient_19_8::/Users/mkrasa/bin:/Users/mkrasa/.local/bin:/Users/mkrasa/.local/bin:/Users/mkrasa/.rd/bin:/Users/mkrasa/bin/oracle/instantclient_19_8::/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/usr/local/go/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/mkrasa/.cargo/bin:/Users/mkrasa/.fig/bin:/Users/mkrasa/.local/bin:/Users/mkrasa/Library/Python/3.11/bin:/Users/mkrasa/.ssh/pic-tools/pic-tools/scripts/bin:/Users/mkrasa/.ssh/pic-tools/pic-tools/scripts/bin
    - SHELL: /bin/zsh
    - TERM: xterm-256color
    - __CFBundleIdentifier: com.googlecode.iterm2
    - FIG_PID: 77104
    - FIG_SET_PARENT: ecf61dd3-194f-4233-8abb-f0ccbda4d9bb

[DmytroLitvinov]

+1

[froggologies]

We can use this command fig settings ssh.remote-prompt "<option>" but I'm unsure about the available options.

[michaelkrasa]

I have latest version of fig and I don't have such an option in the cli, but thank you for suggesting it.

On Fri, Oct 20, 2023 at 8:30 AM Fajar Maftuh Fadli @.***> wrote:

We can use this command fig settings ssh.remote-prompt "" but I'm unsure about the available options.

— Reply to this email directly, view it on GitHub https://github.com/withfig/fig/issues/2780#issuecomment-1772161521, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPGBBR7ELEKWV7OZLCKGRLYAILCBAVCNFSM6AAAAAA6HIJAKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZSGE3DCNJSGE . You are receiving this because you authored the thread.Message ID: @.***>

[froggologies]

I can reset this setting by deleting the ssh.remote-prompt line in ~/.fig/settings.json, then I run fig restart.

[igormages]

What is this mess? I didn't notice it at first, but I think I might have accepted this setting too. What the hell is going on? As soon as I logged into my professional servers, Fig just installs itself like that? What a risk! What nonsense is this? Whose idea was this? And on top of that, there's no option to disable it? Fig, this is going too far.

[michaelkrasa]

@igormages Completely agree, caught me off guard when Fig tried to install itself on a prod machine. Completely unacceptable.

[alphex]

The ssh.remote-prompt setting isn't in that settings.json file.

I had to delete Fig entirely to stop this from happening.

This behavior started for me very recently, after I updated to OSX SONOMA.

[mschrage]

Hey @alphex @michaelkrasa @igormages @FajarMaftuhFadli @DmytroLitvinov - thank you for reporting this.

We are going to release a build that removes this auto-prompting behavior entirely. In the meantime, I suggest following these steps:

1. To uninstall Fig on a remote machine, ssh into that machine and run fig uninstall.
2. To prevent Fig from ever prompting you to install the CLI on a remote machine, run fig settings ssh.remote-prompt never.

[Sam-Sundar]

Even i'm pretty sure i haven't enabled the setting. It starts installing fig the moment i log into a server.

Now worst part is, fig settings ssh.remote-prompt never isn't working. Removing ssh.remote-prompt from ~/.fig/settings.json isn't working. Now it's there enabled by default and some of my critical machines have fig installed.

This isn't acceptable. Provide a way to fix this for now before you guys release a new build @mschrage

[Scotty42]

@Sam-Sundar, you might want to try commenting fig sh include in ~/.ssh/config. Did the trick for me

[phithu]

+1

[haliliceylan]

I was in training, suddenly a fig was installed to the training server?

[Haofei]

this cause trouble in our production server. what a mess

[maxious]

This is also happening with git when using SSH remotes (including github). Oddly the autoinstall tries to install fig using apt on my local machine which is macos and fails:

% curl -fSsL https://fig.io/install-headless.sh | bash; exec $SHELL
███████╗██╗ ██████╗
██╔════╝██║██╔════╝
█████╗  ██║██║  ███╗
██╔══╝  ██║██║   ██║
██║     ██║╚██████╔╝
╚═╝     ╚═╝ ╚═════╝.io
Performing compatibility checks
Executing https://repo.fig.io/scripts/apt/install.sh
% uname -s
Darwin

[Pringlers]

What am I supposed to do when it does not even delete itself correctly? @mschrage

[johnpoint]

There is not even a retry interval, and the logs fill up the hard disk.

[haliliceylan]

There is not even a retry interval, and the logs fill up the hard disk.

The same happened to me on the production server 2 days ago!!! I deleted Fig from the entire team and servers 👎

[VectorXHD]

Same for me.

Didn't work when i deleted ssh.remote-prompt settings

I managed to disable it with this fig integrations uninstall ssh then fig restart

[kokoshneta]

What am I supposed to do when it does not even delete itself correctly? @mschrage

Almost same issue here. Trying to uninstall fig on the remote server gave this result:

xyz123@remote-machine:~$ fig uninstall

* Fig not working? Run fig doctor
* Autocomplete doesn't "feel" right? Watch https://fig.io/l/configuring-autocomplete
* Keep Fig but disable Autocomplete? Run fig settings autocomplete.disable true

✔ Do you want to continue uninstalling Fig? · Yes
Uninstalling Fig
[sudo] password for xyz123:
fig_desktop: no process found
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  fig-headless
0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 83454 files and directories currently installed.)
Removing fig-headless (2.15.0) ...
Uninstalling additional components...
runuser: user xyz123 xyz123 does not exist or the user entry does not contain all the required fields
runuser: user xyz123 xyz123 does not exist or the user entry does not contain all the required fields
error: Failed to uninstall properly
bash: /usr/bin/fig: No such file or directory
xyz123@remote-machine:~$ fig uninstall
bash: /usr/bin/fig: No such file or directory
bash: /usr/bin/fig: No such file or directory

(No idea why uninstalling Fig would double the user name?!?)

The fig executable was seemingly removed, but not whatever it is that causes the remote machine to attempt to run Fig every time I SSH in, so now SSH’ing in rather annoyingly yields this every time:

me@local-machine % ssh xyz123@remote-machine
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-91-generic x86_64)

 // [various informational stuff]

Last login: Fri Jan 19 16:58:31 2024 from [IP address]
Command 'fig' not found, did you mean:
  command 'kig' from snap kig (23.08.3)
  command 'tig' from deb tig (2.5.1-1)
  command 'dig' from deb bind9-dnsutils (1:9.18.18-0ubuntu0.22.04.1)
  command 'fio' from deb fio (3.28-1)
  command 'kig' from deb kig (4:21.12.3-0ubuntu1)
  command 'pig' from deb bsdgames (2.17-29)
  command 'fis' from deb redboot-tools (0.7build4)
  command 'wig' from deb wig (0.6-2)
  command 'xfig' from deb xfig (1:3.2.8b-1)
  command 'rig' from deb rig (1.11-1.1)
  command 'fim' from deb fim (0.5.3-9)
  command 'fid' from deb id-utils (4.6.28-20200521ss15dab)
See 'snap info <snapname>' for additional versions.
Command 'fig' not found, did you mean:
  command 'kig' from snap kig (23.08.3)
  command 'kig' from deb kig (4:21.12.3-0ubuntu1)
  command 'wig' from deb wig (0.6-2)
  command 'tig' from deb tig (2.5.1-1)
  command 'dig' from deb bind9-dnsutils (1:9.18.18-0ubuntu0.22.04.1)
  command 'fim' from deb fim (0.5.3-9)
  command 'rig' from deb rig (1.11-1.1)
  command 'fis' from deb redboot-tools (0.7build4)
  command 'xfig' from deb xfig (1:3.2.8b-1)
  command 'fid' from deb id-utils (4.6.28-20200521ss15dab)
  command 'fio' from deb fio (3.28-1)
  command 'pig' from deb bsdgames (2.17-29)
See 'snap info <snapname>' for additional versions.

I’ve removed the Fig hooks from ~/.bashrc on the remote machine, which didn’t help, but I have no idea where else the instruction to call Fig on login may be coming from.

[Pringlers]

There is not even a retry interval, and the logs fill up the hard disk.

Same. Fig's log filled 4TB in /tmp and somewhere else, and my production service was down due to this.

[schoemme]

I ran fig settings ssh.remote-prompt ask to change it back to always asking. Then fig restart, and it's back to normal for me.

[haliliceylan]

There is not even a retry interval, and the logs fill up the hard disk.

Same. Fig's log filled 4TB in /tmp and somewhere else, and my production service was down due to this.

Same problem, WTF IS THIS ???