.--~~~~~~~~~~~~~------.
/--===============------\
| |```````````````| |
| | | |
| | >_< | |
| | | |
| |_______________| |
| ::::|
'======================='
//-"-"-"-"-"-"-"-"-"-"-\\
//_"_"_"_"_"_"_"_"_"_"_"_\\
[-------------------------]
\_________________________/
hterm and Secure Shell
Frequently Asked Questions
Hello World. This is the hterm/Secure Shell FAQ. If you have a question that is not answered here, please ask it on the chromium-hterm mailing list.
Secure Shell is a Chrome Application that combines the “ssh” command (see https://www.openssh.com/ for details) ported to NativeClient with the “hterm” terminal emulator to provide a secure shell client for the Chrome browser.
Secure Shell provides similar functionality to PuTTY on Microsoft Windows(c) systems, and the ssh command-line application on Mac OS X and Linux systems.
“HTML Terminal”, or hterm, is an xterm-compatible terminal emulator written entirely in JavaScript.
It is intended to be fast enough and correct enough to compete with native terminals such as xterm, gnome-terminal, konsole and Terminal.app.
hterm is only a terminal emulator. It does not provide SSH access (or any other text-based command) on its own.
See chromeos-crosh.md in this directory for the details.
TL;DR - Don't use crosh for ssh any more, use the Secure Shell app instead. The crosh shell will use the newer terminal emulator from Secure Shell when possible.
Chrome Apps were launched to create applications using web technology that would work like native apps on any platform Chrome runs on. Secure Shell was built on that technology.
Fast forward a few years and Chrome Apps were deprecated on all non-Chrome OS platforms. That means the Secure Shell App would only be available on Chrome OS.
In order to work on non-Chrome OS platforms, we need to migrate it to an extension. Unfortunately, doing so means we‘d lose access to some APIs that we use on Chrome OS specifically. The only option we’re left with is to maintain both an extension and an app at the same time.
If you do not care about the Chrome OS specific features, then the two versions are equivalent. Here are the few features available in the App:
That is why we have a “Secure Shell App” and a “Secure Shell Extension” in the store (as well as “dev” versions of each). You can safely have any of them installed simultaneously.
hterm stands out from many existing web terminals in that it was built from the start to match the performance and correctness of “native” terminals such as xterm and Terminal.app.
It can handle large bursts of text quickly, support very large scrollback buffers, and it closely matches xterm's behavior. The keyboard even mostly works. (ha! See the note about how to get Ctrl+W below.)
The Secure Shell app is different because it does not require a proxy or relay server to function. Secure Shell can make a direct connection to a standard sshd server on any port of the destination machine. Other web terminals require a proxy server in the middle. In some cases you are even required to hand the proxy your credentials in plain text.
First, please continue reading this FAQ to make sure your issue isn't mentioned. Then check the bug list at https://goo.gl/VkasRC.
If you don't see the issue there, you can search the archives of the chromium-hterm mailing list.
If all else fails then join the chromium-hterm mailing list and post about what you've found.
To file an actual report, you can use https://goo.gl/vb94JY. This will route to the right people.
If your bug involves some mis-interpreted escape sequence and you want to file a really useful bug report, then add in a recording of the session. For bonus points, track down the troublesome sequence and include the offset into the log file. For more information about how to do this, see hterm's “Debugging escape sequences” section.
Yes, there is a public chromium-hterm mailing list anyone can join!
Yes. First, you need to subscribe to the chromium-hterm mailing list. Subscribers have access to the “Dev” versions in the Chrome Web Store, which are located here:
Note: You'll also need to sign in to the Chrome Web Store using the same account that joined the mailing list. Otherwise, the link will result in a 404 error.
Please keep in mind that the Dev version has gone through significantly less testing than the stable versions. Fortunately, you can install both and switch back to stable if you have trouble with Dev.
The hterm source is here: https://goo.gl/8qndhN. This includes the front-end code for Secure Shell.
The Native Client wrapper around ssh is here: https://goo.gl/4tZCMI.
Yes. Look under the doc/ directory for each project.
There is one for hterm and one for Secure Shell.
Read the hack.md file in this directory.
No. By default all connections are made directly to the sshd server on the destination machine.
Secure Shell also knows how to connect to an HTTP-to-ssh relay that was built inside Google. Unfortunately that relay isn‘t open source, and Google doesn’t maintain a public pool of relays.
The good news is that someone has built an open source relay. It is not supported by us though, so please take any questions/concerns about it to the author.
For more details on the relay protocol that Secure Shell supports, see the Relay Protocol document.
When using a relay server, Secure Shell only sends the hostname to the remote side that has been specified in the connection settings. The relay server is then responsible for resolving that to an actual IP address (since the name is often unresolvable locally by design!). But the relay server has no way of communicating that IP address back to the client, so Secure Shell just stubs it out with 0.0.0.0. This is harmless and may be safely ignored.
When it comes to the known hosts database, the name will be used instead.
The Secure Shell app uses ssh to manage the encrypted communication channels. This makes it about as secure as any other connection based on the ssh command.
It does have the added advantage of running ssh as a sandboxed Native Client plugin, which in theory makes it more secure than an unsandboxed ssh connection.
Additionally, the Secure Shell application follows a strict Content Security Policy that does not allow access to the JavaScript ‘eval’ function. This helps lower the risk that a terminal exploit could run arbitrary JavaScript.
You can import identity files from the connection dialog. Select the “Import...” link to bring up a file picker.
You must import two files for each identity. One should be the private key and should not have a file extension. The other should be the public key, and must end in “.pub”. For example, “id_rsa” and “id_rsa.pub”.
If you have a key stored in a single “.pem” file, you must split it into two files before importing.
This will import your public/private key files into the HTML5 filesystem associated with Secure Shell. There should be no way for another extension, app, or web page to access this sandboxed filesystem.
Keep in mind that HTML5 filesystems are relatively new. As always, it's possible that there are still exploits to be found or disclosed.
Additionally, Chrome stores HTML5 filesystems as normal files (with mode 600, “-rw-------”) under your profile directory. Non-Chrome applications on your system may be able to access these files.
For your own good, protect your important private keys with a strong passphrase.
You can also import a traditional ssh ‘config’ file using this dialog. Nearly anything that ssh might care about from your ~/.ssh directory can go here.
See http://man.openbsd.org/ssh_config for more information about the ssh configuration syntax. Keep in mind that any directives that would require access outside of the NaCl sandbox will not function properly. This includes (but is not limited to) X11 forwarding, syslog functionality, and anything that requires a domain socket.
Connection and preference information are synced to the cloud according to your Chrome sync settings. SSH private keys are only stored locally and not placed in sync storage. If you delete your Chrome profile or switch machines, you'll have to re-import them.
Probably. It depends on what it does. See the answer to the previous question for more details.
Not at this time, and most likely won't be supported.
If you were able to run an existing X client locally (like XWayland), and tell it to listen on a local TCP/IP port, you could add SSH forwarding options so the remote side would be able to export their clients to that instance.
For context, this is referring to the X Window System, the method for displaying graphics on many UNIX systems like Linux and BSDs.
Since Secure Shell runs in a sandbox (by design), it doesn‘t have direct access to host paths such as the UNIX socket that X listens on. That means it can’t forward access to it to the remote system.
Even if it did have such access, it would only work when the local system was also running X. Chrome OS long ago stopped using X (instead, it switched to “freon” which is a native graphics stack like Wayland), and many Linux distros are also switching away from X. That means the userbase is shrinking.
We're not going to implement a custom protocol parser for X so the client would be able to handle/render everything itself. The amount of code to do so would be significant.
Not anymore. The SSH-2.0 protocol has been available for over a decade. If you need this, then try contacting the chromium-hterm mailing list. Your best bet though would be to upgrade the server, or find a different system/client to connect to the old system.
It is disabled by default at runtime. You can enable it by adding -oKexAlgorithms=+diffie-hellman-group1-sha1 to your ssh command line in the connection page.
However, these key types are insecure. You should update your server to newer key types like RSA or ED25519. Future support for these key types is not guaranteed.
See the OpenSSH legacy options page for more details.
It is disabled by default at runtime. You can enable it by adding -oHostKeyAlgorithms=+ssh-dss to your ssh command line in the connection page.
However, these key types are insecure. You should update your server to newer key types like RSA or ED25519. Future support for these key types is not guaranteed.
See the OpenSSH legacy options page for more details.
Not anymore. You'll need to use a different client to connect if those are the only ciphers your server supports.
Secure Shell uses OpenSSH, and OpenSSH has deprecated or dropped these as they are legacy and weak or insecure.
You can find out what ciphers are still supported by adding -Q ciphers to the ssh command line. If the cipher you want is listed there, you can use the -c option on the ssh command line to enable it.
If the cipher you want is not listed there, then it isn‘t supported. You’ll need to use a different client to connect if those are the only ciphers your server supports.
See the OpenSSH legacy options page for more details.
Not anymore. Keys smaller than 1024 bits are insecure. You'll need to generate new keys and use those instead.
If you still need to connect to such a system, you'll have to use a different client to connect.
Not anymore. You'll need to use a different client to connect if those are the only ciphers your server supports.
See the OpenSSH legacy options page for more details.
The easiest way is to visit the options page and select the “SSH Files” section on the left. From there you will find a list of all the identities and you can delete individual ones.
From the connection dialog, select an identity from the dropdown and press the DELETE key. This will remove both the private and public key files from the HTML5 filesystem.
Open the JavaScript console and type...
term_.command.removeDirectory('/.ssh/')
This will remove any non-key files you may have uploaded as well. It will not affect your preferences.
Sorry, not yet. This is a bit of a technical challenge given the nature of the NaCl sandbox. We have a few options that we're exploring. Feel free to post your ideas to the chromium-hterm mailing list.
(And yes, we're already considering integrating with the Chrome NSS certificate store.)
Yes (although see next section on zone ids). You can connect to hostnames that resolve to IPv6 addresses, and you can connect directly to IPv6 addresses. Enter them in the connection manager like any other hostname or IPv4 address.
When using links (see the bookmark section below), you'll need to use the standard bracket style such as [::1].
Unfortunately, we can only support what the browser supports, and Chrome does not currently support zone ids.
Note: Zone ids are sometimes incorrectly referred to as scope ids.
Mostly. You can create a few types of bookmarks:
ssh:// URL.Note that Chrome opens bookmarks in new tabs. If you want to have a bookmark open as a window, add ?openas=window to the URI (before #).
In the examples below, the [ID] field will need adjusting based on the version you have installed:
pnhechapfaindjhompbnflcldabbghjo: Secure Shell App (stable)okddffdblfhhnmhodogpojmfkjmhinfp: Secure Shell App (dev)iodihamcpbpeioajjeobimgagajmlibd: Secure Shell Extension (stable)algkcnfjnajfhgimadimbjhmpaeohhln: Secure Shell Extension (dev)The first one takes the form of:
chrome-extension://[ID]/html/nassh.html#user@host[:port][@proxyhost[:proxyport]]
The user and host fields are mandatory, but you can omit the :port if you like (as well as the proxy settings). There is no way to customize any other field/connection property.
Here is an example for connecting to the server cowfarm as user milkman:
chrome-extension://[ID]/html/nassh.html#milkman@cowfarm
And on port 2222:
chrome-extension://[ID]/html/nassh.html#milkman@cowfarm:2222
The second method requires you to first create a new connection in the connection dialog, and then you can bookmark that connection directly. It then takes the form of:
chrome-extension://[ID]/html/nassh.html#profile-id:ID
The ID part will need to be changed to match the unique id assigned to each connection. You can find it by loading Secure Shell into a tab, connecting to the profile, then looking at the URL box. This allows you to fully control the ssh parameters though: you may add arguments or change the command line or relay settings.
You can create ssh:// links that will automatically open Secure Shell. They take the same form as Direct links above. See uri.md in this directory for the details.
Mostly. See the previous question about bookmarks.
Yep! Type “ssh” followed by a space to start a quick connection, then type a match to an existing profile, or type a new connection using the format defined in the Direct links section above.
You can open it in the existing tab by pressing Enter, or opening it in a new window by pressing Alt+Enter, or opening it in a new background tab by pressing Command+Enter/Meta+Enter.
Since every Secure Shell instance registers the “ssh” keyword, Chrome has to pick one. Chrome goes by the order they were installed, so whichever version was installed first, that's the default.
If you want to change the default, you'll have to delete the others from the search engine list. See the next question for more details.
Chrome currently doesn't have a way to re-add them if you change your mind other than uninstalling & reinstalling extensions. Make sure to back up your settings so you can restore them.
When trying to search for “ssh” via the omnibox, it might trigger the app when you actually want to perform a search. Here are some alternatives:
? to force a search. i.e. Use ?ssh ... instead of ssh ....If you want to always disable this integration, you can do so in the standard search engine management settings page. It'll be at the very bottom under “Search engines added by extensions”. See the Google Chrome Help page for more details.
Yes. Enter your port forwarding options in the “SSH Arguments” field of the connect dialog. The port forward will be active for the duration of the Secure Shell session.
The easiest way to modify the file is to visit the options page and select the “SSH Files” section on the left. From there you will find text fields to edit the various files including the known_hosts database.
You can also hold Ctrl while right clicking the terminal to bring up a context menu. Under that is an option to clear all SSH known hosts.
This is the last field in the connect dialog. It allows you to select which set of terminal preferences to use for the connection.
If you name a terminal profile that doesn't yet exist, it will be created and all preferences will be set to their default value. Any preference changes will affect the active terminal profile only.
For example, enter “light” as the name of a terminal profile for a new connection. Once you‘ve connected, change the color scheme to black-on-white (as described in the FAQ entried below). That change will be associated with the “light” profile, and you’ll be able to re-use it for other saved connections.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Appearance section. The documentation below is meant for people hacking on the source directly.
In general, you open the JavaScript console and type something like...
term_.prefs_.set('pref-name', 'pref-value')
Preferences are saved in your local storage, so they're remembered the next time you launch Secure Shell.
If you want to check the current value of a preference, type this...
term_.prefs_.get('pref-name')
To reset a single preference to its default state, type this...
term_.prefs_.reset('pref-name')
To reset all preferences to their default state, type this...
localStorage.clear()
Most preference changes take effect immediately, in all open instances of Secure Shell. The exception is the ‘environment’ setting, which won't take effect until the next time you reconnect.
Some common preferences are listed in questions that follow. For the full list, you‘ll have to read through the “definePreferences” call in hterm_preference_manager.js. It’s here: https://goo.gl/xZa38d, around line 130.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Sounds section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('audible-bell-sound', 'http://example.com/bell.ogg')
Change the example url to point to the sound file you want to use. Unfortunately, local file: urls are not supported at this time. If you want to get fancy you could construct a data: url, but the details of that are beyond the scope of this FAQ.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Sounds section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('audible-bell-sound', '')
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Appearance section. The documentation below is meant for people hacking on the source directly.
You can change the foreground, background or cursor color preferences from the JavaScript console like this...
term_.prefs_.set('background-color', 'wheat')
term_.prefs_.set('foreground-color', '#533300')
term_.prefs_.set('cursor-color', 'rgba(100, 100, 10, 0.5)')
You can use any valid CSS color value for any of these colors. You need to use a semi-transparent color (the fourth parameter in the rgba value) for the cursor if you want to be able to see the character behind it.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Appearance section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('font-family', 'Lucida Console')
Replace ‘Lucida Console’ with your favorite monospace font.
Keep in mind that some fonts, especially on Mac OS X systems, have bold characters that are larger than the non-bold version. hterm will print a warning to the JS console if it detects that you've selected a font like this. It will also disable “real” bold characters, using only bright colors to indicate bold.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Appearance section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('font-size', 15)
Replace 15 with your desired font size in pixels. 15 is the default, so you'll have to pick a different number to have any effect at all.
You can define it in the CSS file loaded via the ‘user-css’ field, or you can inline the content in ‘user-css-text’.
Here is an example using Google Web Fonts. Add this line to your custom CSS, and add "Roboto Mono" to your ‘font-family’ list.
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono');
Here is an example for Powerline Fonts. Add this text to your custom CSS, and add "Anonymous Pro" to your ‘font-family’ list.
@font-face {
font-family: "Anonymous Pro";
src: url(https://cdn.rawgit.com/wernight/powerline-web-fonts/8040cf32c146c7cd4f776c1484d23dc40685c1bc/fonts/AnonymousPro.woff2) format("woff2");
}
By default, we disable ligatures. Some fonts actively enable them like macOS's Menlo (e.g. “ae” is rendered as “æ”). This messes up copying and pasting and is, arguably, not terribly legible for a terminal.
If you're using a font that supports ligatures, and you want to use them, you can enable them via the ‘user-css-text’ field:
x-row {
text-rendering: optimizeLegibility;
font-variant-ligatures: normal;
}
For more details, check out this Ligatures & Coding article.
Yes. The Ctrl+Plus, Ctrl+Minus and Ctrl+Zero keys can increase, decrease, or reset the current font size. This zoomed size is not remembered the next time you start hterm. See the previous question if you want something that will stick.
It‘s useful to know that hterm has to handle font zooming on its own. Without interference from the browser’s built-in zoom function.
The browser zoom introduces rounding errors in pixel measurements that make it difficult (maybe impossible) for hterm to accurately position the cursor on the screen. (It could do a little better than it does but probably not enough to be worth the effort.)
To mitigate this, hterm will display a warning message when your browser zoom is not 100%. In this mode the Ctrl+Plus, Ctrl+Minus and Ctrl+Zero keys are passed directly to the browser. Just press Ctrl+Zero to reset your zoom and dismiss the warning.
hterm should start handling Ctrl+Plus, Ctrl+Minus and Ctrl+Zero on its own once your zoom setting is fixed.
Because hterm requires you to set your browser to 100%, or 1:1 zoom. Try Ctrl+Zero or the Wrench->Zoom menu to reset your browser zoom. The warning should go away after you correct the zoom level.
See the previous question for more information.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Appearance section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('font-smoothing', 'none')
This directly modifies the ‘-webkit-font-smoothing’ CSS property for the terminal. As such, ‘none’, ‘antialiased’, and ‘subpixel-antialiased’ are all valid values.
The default setting is ‘antialiased’.
You can customize these via the ‘user-css’ or ‘user-css-text’ fields.
There are two mouse styles you will encounter: text and pointer. The ‘text’ style is the one you'll see most of the time and is the “i-beam” by default. The ‘pointer’ style is used when the terminal is in “mouse mode”.
Here's an example to change them:
:root {
--hterm-mouse-cursor-text: url("https://developer.mozilla.org/files/3809/text.gif") 14 13, text;
--hterm-mouse-cursor-pointer: url("https://developer.mozilla.org/@api/deki/files/3449/=pointer.gif") 14 13, pointer;
}
The two numbers after the url(...) are optional. They are pixel offsets to control the center/focus of the cursor. Feel free to adjust them until the mouse cursor feels natural.
Remember to specify a fallback keyword (text and pointer in the example) when using url(...), otherwise the browser will silently ignore the setting.
For more details on the syntax, consult the MDN documentation.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Appearance section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('cursor-blink', true)
Notice that true is NOT in quotes. This is especially important if you try to turn blinking back off, with...
term_.prefs_.set('cursor-blink', false)
or you could just revert to the default value of false with...
term_.prefs_.reset('cursor-blink')
Most terminals ignore attempts by the host to change the blink-state of the cursor. This lets you choose between a blink/steady cursor via the cursor-blink preference, without having the host change your setting.
By default, hterm also ignores this escape sequence. To enable it, set the ‘enable-dec12’ preference to true.
term_.prefs_.set('enable-dec12', true)
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Misc section. The documentation below is meant for people hacking on the source directly.
Open the JavaScript console and type...
term_.prefs_.set('environment', {TERM: 'hterm'})
Notice that only ‘hterm’ is quoted, not the entire value. You can replace ‘hterm’ with whichever value you prefer.
The default TERM value is ‘xterm-256color’. If you prefer to simulate a 16 color xterm, try setting TERM to ‘xterm’.
You will have to reconnect for this setting to take effect.
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Keyboard section. The documentation below is meant for people hacking on the source directly.
That depends on your platform and which accented characters you want to enter.
In xterm, you could use Alt+plus-a-letter-or-number to select from the upper 128 characters. The palette of 128 characters was “hardcoded” and not dependent on your keyboard locale. You can set hterm to do the same thing by opening the JavaScript console and typing...
term_.prefs_.set('alt-sends-what', '8-bit')
However, if you are on Mac OS X and you prefer that Alt sends a character based on your keyboard locale, try this instead...
term_.prefs_.set('alt-sends-what', 'browser-key')
Note that composed characters (those that require multiple keystrokes) are not currently supported by this mode.
If you are running Chrome OS on a Chromebook you can select your keyboard locale from the system settings and just use the Right-Alt (the small one, on the right) to enter accented characters. No need to change the ‘alt-sends-what’ preference at all.
The default value for ‘alt-sends-what’ is ‘escape’. This makes Alt work mostly like a traditional Meta key.
If you really, really want Alt to be an alias for the Meta key in every sense, use...
term_.prefs_.set('alt-is-meta', true)
You should manage your preferences under the Secure Shell Options page. Just right click the app in Chrome, select Options, and see the Keyboard section. The documentation below is meant for people hacking on the source directly.
By default, hterm sends a delete (DEL, ‘\x7f’) character for the backspace key. Sounds crazy, but it tends to be the right thing for most people. If you'd prefer it send the backspace (BS, ‘\x08’, aka ^H) character, then open the JavaScript console and type...
term_.prefs_.set('backspace-sends-backspace', true)
Chrome blocks tab contents from getting access to these (and a few other) shortcuts. You can open Secure Shell in a dedicated window to get around this limitation. The exact method depends on a few factors.
If you're running the app (not the extension), right-click on the Secure Shell icon and enable “Open as Window”. After that, any time you launch Secure Shell it will open in a new window and handle these directly. This feature is not available on macOS however (see below).
If you're running the extension, Secure Shell opens as a window normally, and the shortcuts should be caught automatically.
If you want to run Secure Shell in a tab, then unfortunately Chrome offers no option currently to capture these keystrokes. See https://crbug.com/671774 for more details. You could run it in fullscreen mode (by pressing F11), but that isn't a great option if you want to leverage tabs. You could press F11, then Ctrl+N, then F11 again, but that also is not great.
If you want to open another Secure Shell session, use Ctrl+Shift+N.
Bookmarks will open in a tab regardless of OS and any settings. You can add ?openas=window to the URI so Secure Shell will reopen itself as a window automatically.
On macOS, most shortcuts are initiated via the Cmd key, so Ctrl shortcuts are passed regardless of the mode (window or tab), so this is generally less of an issue on this platform. If you want to capture Cmd-W, etc..., then currently there is no way to do so. If you're OK with changing system wide settings, there are some third party keyboard utilities that may help, or try searching for changing keyboard shortcuts.
If you want to launch Secure Shell directly from the command line (or an OS desktop shortcut), you can use the --app=... option. For example: chrome --app=chrome-extension://iodihamcpbpeioajjeobimgagajmlibd/html/nassh.html#profile-id:e431 ...
In Chrome OS, Ctrl+Shift+Space and Ctrl+Space are used to cycle through keyboard input methods. By default, hterm will capture these. You can turn on the ‘keybindings-os-defaults’ setting, or add custom bindings for these in the ‘keybindings’ settings to pass them along to the OS instead.
{
"Ctrl+Shift+Space": "PASS",
"Ctrl+Space": "PASS"
}
For more details, see the Can I rebind keys/shortcuts section below.
In newer versions of macOS, holding down many keys (like a) won‘t repeat the key. Instead, you’ll get a pop up with an accent menu so you can select between à, á, â, ä, æ, etc... This is a macOS feature that cannot be disabled on a per-application basis.
If you don't like this behavior, you can disable it in Chrome by opening a terminal and running:
defaults write com.google.Chrome ApplePressAndHoldEnabled -bool false
Or disable it globally by running:
defaults write -g ApplePressAndHoldEnabled -bool false
Yes, all keys can be rebound. Look for the ‘keybindings’ setting in the Secure Shell Options page under the Keyboard section.
For more documentation on the format, see the Keyboard Bindings doc.
By default, Secure Shell automatically copies your active selection to the clipboard.
You can disable this by setting the ‘copy-on-select’ preference to false. If you disable it you'll need to use one of the following key sequences to copy to the clipboard...
Under Mac OS X the normal Command+C sequence works.
On other platforms Ctrl+C will perform a Copy only when text is selected. When there is no current selection Ctrl+C will send a “^C” to the host.
Note that after copying text to the clipboard the active selection will be cleared. If you happen to have text selected but want to send “^C”, just hit Ctrl+C twice.
Under all platforms you can also use the “Copy” command from the Wrench menu, when running Secure Shell in a browser tab.
By default, Shift+Insert pastes the clipboard on all platforms. If you'd prefer to be able to send Shift+Insert to the host, set the ‘shift-insert-paste’ preference to false.
Also...
Under Mac OS X the normal Command+V sequence can be used to paste from the clipboard.
On other platforms use Ctrl+Shift+V to paste from the clipboard.
Under X11, you can use middle-mouse-click to paste from the X clipboard.
Under all platforms you can also use the “Paste” command from the Wrench menu.
This answer only applies if you've set the ‘enable-dec12’ preference to true.
Do you normally use Terminal.app or xterm? Those terminals (and many others) ignore the “ESC [ ? 12 h” and “ESC [ ? 12 l” sequences (DEC Private Mode 12). Emacs uses these sequences (on purpose) to enable and disable cursor blink.
If you prefer a steady cursor in emacs, set visible-cursor to nil as described in https://goo.gl/muppJj.
hterm's default value for the TERM environment variable is ‘xterm-256color’. This causes emacs, vi, and some other programs to use a different color palette than when TERM=‘xterm’.
You may notice these programs use a font color that is difficult to read over a dark background (such as dark blue).
You can fix vi with ‘:set bg=dark’. Emacs can be started in “reverse video” mode with ‘emacs -rv’.
If you just want your old 16 color palette back, open the JavaScript console and type...
term_.prefs_.set('environment', {TERM: 'xterm'})
Then restart Secure Shell.
The default terminal encoding used by hterm is UTF-8. Historically, and in other terminals, it was ISO 2022. That means support for changing character sets to e.g. graphics sets is disabled by default. This makes the terminal more robust as you no longer have to worry about accidentally running cat on a binary file corrupting your terminal output.
Unfortunately, ncurses insists on using these legacy encodings by default instead of using modern UTF-8 in its output. So until ncurses fixes its behavior, things can easily get out of sync.
One way to work around this is to instruct ncurses to stick to pure UTF-8 output by adding to your shell's startup script (e.g. ~/.bashrc):
export NCURSES_NO_UTF8_ACS=1
Another option is to change the terminal encoding on the fly via the standard DOCS escape sequence:
printf '\x1b%%@'
You could work around it by changing the default encoding back to ISO 2022 in your preferences. Look for the terminal-encoding option and change it to iso-2022.
For more technical details, check out the mosh docs, Markus Kuhn‘s UTF-8 terminal emulator issues, and hterm’s DOCS and SCS documentation.
Sort of. Both emacs and vi have mouse modes that are compatible with Secure Shell.
In emacs, use M-x xterm-mouse-mode and M-x mouse-wheel-mode. This will allow you to position the cursor with a mouse click, and use the wheel (or two-finger scroll) to scroll the buffer.
In vi, use “:set mouse=a” to enable mouse mode.
When using the alternative screen buffer, and DECCKM (Application Cursor Keys) is active, mouse wheel scroll events will emulate arrow keys. That means when you scroll the wheel up, it will behave like you pressed the up arrow key a few times instead.
This often shows up when using programs like pagers (less) or reading man pages or using text editors (vi/nano) or using screen/tmux (which you might see as scrolling through command history in the shell).
You can disable this feature temporarily by holding the shift key. This way you can scroll the buffer in some cases (like screen) while still supporting emulation in programs where it's more useful (like pagers and man).
You can disable this feature permanently via the scroll-wheel-may-send-arrow-keys preference.
Clipboard writing is allowed by default, but you can disable it if you're paranoid. Set the ‘enable-clipboard-write’ preference to false to disable the control sequence.
Clipboard read is not implemented. Reading is a security hole you probably didn't want anyway.
Clipboard writes are triggered by an escape sequence from the host. Here's an example...
$ printf "\033]52;c;Y29weXBhc3RhIQ==\a\n"
The sequence \003]52; identifies this as a clipboard operation. The c; option selects the system clipboard. Y29weXBhc3RhIQ== is the base64 encoded value to place on the clipboard, in this case it's the string “copypasta!”. Finally, \a terminates the sequence.
If you execute this command when ‘enable-clipboard-write’ on you should see the “Selection Copied” message appear in the terminal, and your system clipboard should contain the text, “copypasta!”.
Note that the specification for OSC 52 mentions destinations other than the c; system clipboard. Hterm treats them all as the system clipboard.
There is an osc52.sh helper script available as well:
$ echo "hello world" | osc52.sh
Yes -- for Vim, see osc52.vim. For Emacs versions prior to Emacs 25, see osc52.el (newer Emacs versions have built-in OSC-52 support). osc52.vim works inside tmux and screen sessions.
Since screen/tmux create their own terminals to capture and process output even when you aren't connected, they end up processing all the control sequences and then mangling/passing on only the ones they understand. That means if you try to use a sequence that only hterm understands, it will get silently swallowed/discarded. However, these systems usually provide a way to pass thru content directly to the active terminal.
Under screen, you can use a DCS sequence (ESC+P). Replace the ... part with what you want to send (and remember to escape the escapes).
# A DCS sequence terminated by a ST. $ printf '\033P...\033\\' # Send a notification straight to hterm. $ printf '\033P\033\033]777;notify;title;body\a\033\\'
Under tmux, you can use a DCS sequence too, but using the tmux subcommand. Replace the ... part with what you want to send (and remember to escape the escapes).
# A DCS sequence terminated by a ST. $ printf '\033Ptmux;...\033\\' # Send a notification straight to hterm. $ printf '\033Ptmux;\033\033]777;notify;title;body\a\033\\'
There is an hterm-notify.sh helper script available as well:
$ hterm-notify.sh "Some Title" "Lots of text here."
We support the iTerm2‘s OSC 1337 file transfer sequence. The protocol is a little bit complicated, so there’s a hterm-show-file.sh helper script for you. iTerm2's “imgcat” script should also work.
For more details on the options available, see the specification.