Does Terminal app have access to chrome.storage.sync?

84 views
Skip to first unread message

Yiyue Wang

unread,
Apr 8, 2025, 2:33:44 AMApr 8
to chromium-hterm
If not, is there a way to set the /etc/ssh/ssh_known_hosts value for Terminal app?

Keith Dickey

unread,
Apr 8, 2025, 2:37:28 AMApr 8
to Yiyue Wang, chromium-hterm

Yes, there is a way to set the /etc/ssh/ssh_known_hosts value that the Terminal app (and any other SSH client) will use.
The /etc/ssh/ssh_known_hosts file is a system-wide file that stores the host keys of SSH servers you've connected to. When you connect to an SSH server for the first time, SSH will prompt you to verify the host key and, if you agree, it will be added to this file (or your user-specific ~/.ssh/known_hosts file). Subsequent connections to the same server will be checked against this stored key to prevent man-in-the-middle attacks.
You can directly edit the /etc/ssh/ssh_known_hosts file using a text editor with administrator privileges (root or via sudo).
Here's how you can do it:
* Open Terminal: Launch your Terminal application.
* Gain Administrator Privileges: Use the sudo command to open the file with elevated permissions. You'll likely be prompted for your password.
   sudo nano /etc/ssh/ssh_known_hosts

   or you can use other text editors like vim or gedit:
   sudo vim /etc/ssh/ssh_known_hosts

   sudo gedit /etc/ssh/ssh_known_hosts

* Edit the File:
   * Adding a new host key: If you have the host key of a server you want to trust beforehand, you can add a new line to this file with the server's hostname (or IP address), the key type (e.g., ecdsa-sha2-nistp256), and the actual host key. The format typically looks like this:
     hostname,IPaddress key_type base64_encoded_key comment

     For example:
     example.com,192.168.1.10 ecdsa-sha2-nistp256 AAAAE...long_base64_string... us...@example.com

   * Removing an existing host key: If you need to remove an entry (for example, if the host key of a server has changed), simply find the line corresponding to that server and delete it.
   * Modifying an existing host key: If a server's host key has legitimately changed, you can edit the existing line with the new key. Be very cautious when doing this, as it could indicate a security risk if the key changed unexpectedly. Always verify the new key through a trusted channel.
* Save and Close: After making your changes, save the file and close the text editor.
   * In nano: Press Ctrl+O to write out (save), then press Enter. Press Ctrl+X to exit.
   * In vim: Press Esc, then type :wq and press Enter to write and quit.
   * In gedit: Click the "Save" button and then close the window.
Important Considerations:
* Security Risk: Manually editing known_hosts files can introduce security risks if you add an incorrect or malicious host key. Always ensure you are getting the correct host key from a trusted source.
* User-Specific known_hosts: It's often preferable to use the user-specific ~/.ssh/known_hosts file instead of the system-wide one. This file is located in your home directory (/home/your_username/.ssh/known_hosts). Changes to this file only affect your user. You can edit it in the same way as the system-wide file, but without needing sudo.
* ssh-keygen -R: A safer way to remove a specific host key from either known_hosts file is to use the ssh-keygen command with the -R option:
   ssh-keygen -R hostname_or_IP -f /etc/ssh/ssh_known_hosts

   or for the user-specific file:
   ssh-keygen -R hostname_or_IP -f ~/.ssh/known_hosts

* ssh-keyscan: To obtain the host key of a server, you can use the ssh-keyscan utility:
   ssh-keyscan hostname_or_IP

   You can then redirect the output to your known_hosts file. Be sure to verify the key before trusting it.
Since you are using a Debian environment (as of December 22, 2024), these instructions should be directly applicable. Remember to exercise caution when modifying system configuration files.


On Tue, Apr 8, 2025, 2:33 AM 'Yiyue Wang' via chromium-hterm <chromiu...@chromium.org> wrote:
If not, is there a way to set the /etc/ssh/ssh_known_hosts value for Terminal app?

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/995b8049-1c83-45dd-ad10-2e84f750a56fn%40chromium.org.

Mike Frysinger

unread,
Apr 8, 2025, 12:13:16 PMApr 8
to Keith Dickey, Yiyue Wang, chromium-hterm
none of that is correct. the Terminal app has no access to file system resources like /etc files. 
-mike 

Mike Frysinger

unread,
Apr 8, 2025, 12:15:27 PMApr 8
to Yiyue Wang, chromium-hterm
Terminal has its own storage API. I believe it's equivalent to sync in practice, but Joel should confirm. 
-mike 

On Tue, Apr 8, 2025, 02:33 'Yiyue Wang' via chromium-hterm <chromiu...@chromium.org> wrote:
If not, is there a way to set the /etc/ssh/ssh_known_hosts value for Terminal app?

--

Keith Dickey

unread,
Apr 8, 2025, 1:12:45 PMApr 8
to Mike Frysinger, Yiyue Wang, chromium-hterm

What are you using for an OS and what are you using for a virtual environment


Mike Frysinger

unread,
Apr 8, 2025, 1:21:43 PMApr 8
to Yiyue Wang, chromium-hterm
looks like Terminal has per-system configs (~/.ssh/known_hosts), but we didn't plumb through the synced prefs (/etc/ssh/ssh_known_hosts) to the UI.
-mike

On Tue, Apr 8, 2025 at 2:33 AM 'Yiyue Wang' via chromium-hterm <chromiu...@chromium.org> wrote:
If not, is there a way to set the /etc/ssh/ssh_known_hosts value for Terminal app?

--

Yiyue Wang

unread,
Apr 8, 2025, 7:59:11 PMApr 8
to chromium-hterm, vap...@chromium.org, chromium-hterm, Yiyue Wang
Thanks a lot Mike! Does it mean that we can still use chrome.storage.sync on Terminal? Even though it's not visible from the UI

Mike Frysinger

unread,
Apr 8, 2025, 8:15:18 PMApr 8
to Yiyue Wang, chromium-hterm
no, chrome.storage.sync does not work in Terminal.  Terminal has a private API ("chrome.terminalPrivate") that exposes comparable storage API that is synced.  that is what Terminal uses to store preferences.
-mike

Yiyue Wang

unread,
Apr 8, 2025, 8:19:12 PMApr 8
to chromium-hterm, vap...@chromium.org, chromium-hterm, Yiyue Wang
OK I see, thanks so much Mike! I was naive enough to believe that Terminal / Secure shell would just work since they use the same code base. 

In this case I'm assuming that API is not really exposed, is that correct? In order to store something there would there need to be extra work needed on the Terminal side?

Mike Frysinger

unread,
Apr 9, 2025, 12:56:23 AMApr 9
to Yiyue Wang, chromium-hterm
the underlying storage is abstracted away using libdot's storage API.  nassh's command instance simply uses this.syncStorage to read/write settings.  so when running Secure Shell, this.syncStorage is backed by chrome.storage.sync, and when running Terminal, it's backed by chrome.terminalPrivate.  but nassh doesn't need to know/care because libdot's storage API exposes the same interface.
-mike

Yiyue Wang

unread,
Apr 9, 2025, 1:45:03 AMApr 9
to chromium-hterm, vap...@chromium.org, chromium-hterm, Yiyue Wang
Ah I think I understand a bit more now... Found the code to it as well
Thank you so so much Mike!

Moreover, I'm wondering if it's ok that I could book an office hour with you between 7am - midnight my time, which would be after 5pm your time, or between 9am - 10am your time?

Mike Frysinger

unread,
Apr 10, 2025, 11:42:16 AMApr 10
to Yiyue Wang, chromium-hterm
feel free to book in my cal
Reply all
Reply to author
Forward
0 new messages