Small problem with shell integration host detection

Wow, I had no idea about OpenBSD's hostname command :(. I see from its manpage that there's no way to do it using hostname. Do you happen to know if an OpenBSD box can reliably report its fully-qualified domain name?

I'm not sure how to resolve the issue of the host knowing the address you used to reach it, but I'm totally open to suggestions.

mentioned in issue #4194

I think /etc/myname contains the FQDN on OpenBSD boxes... Not 100% sure on that though. Actually, this doesn't appear to contain a resolvable hostname on my box, so maybe not.

How feasible do you think it would be to intercept the hostname when the user runs SSH? Maybe part of the shell integration setup could install a wrapper, so when the user (or a script) calls "ssh", it actually calls some fake SSH that the shell integration script has inserted on PATH before the real SSH. This fake SSH figures out the hostname (either from the command line or from e.g. a host alias in .ssh_config) and lets iTerm2 do its thing without needing to call anything on the remote host, and then the script calls the real SSH. This might be more complicated than I'm imagining, but something along those lines could work with no dependencies on the remote server.

Hi Will,

I've been working on a related issue #4194, and George mentioned your issues in that discussion. I'm working on fixes for that issue and hopefully it will address your issues as well:

obtaining the hostname on OpenBSD, (and more importantly)
allowing for the use of IP Addresses for multi-homed hosts (this may require a feature addition by George)
Note, that the non resolve-able hostname issue also occurs with my AWS instances (so I understand your problem well.)
Check out the latest post in the #4194 thread to see where we're at regarding this fix.

Can you SSH into your OpenBSD host, run the commands below and reply back with the results? Also, if you could run these in a Bash shell that would be great. (The fix will be ported to other shells, but right now I'm working in Bash, and one of my tests uses a bash environment var). Feel free to "sanitize" the IP addresses for privacy, just make sure its clear if they are local-net or public internet addresses.

uname -s - hopefully this will return "OpenBSD"
cat /etc/myname - I realize this won't be a useful value for your situation, but it's useful to understand how your host is configured
dnsdomainname - this utility likely does not exist and thus will fail
echo $SSH_CONNECTION | awk '{split($3, ary, /%/); print ary[1]}' - this uses an environment Var to obtain the IP address from a remote host that you're SSH'd into.
curl -s ipinfo.io/ip - this fetches the public ip address (it requires that the curl utility is installed).
Please let me know which of the two IP addresses returned above allows you to SSH into your host. (They could both be the same, but likely not in your situation.)
Note, I've had problems SSHing into IPv6 Addresses returned from these commands. So, if you get an IPv6 addresses in the results,run ssh with the -4 argument to force an IPv4 connection (and thus get v4 address results)
I know it seems like the SSH_CONNECTION address should always work, but I discovered that my AWS instances have it set to an internal IP address that's not reachable from the internet, thus the reason for fetching the public ip address.

Hey Robert,

-bash-4.2# uname -s
OpenBSD
-bash-4.2# cat /etc/myname
bigbox
-bash-4.2# dnsdomainname
-bash: dnsdomainname: command not found
-bash-4.2# echo $SSH_CONNECTION | awk '{split($3, ary, /%/); print ary[1]}'
192.168.0.5
-bash-4.2# # ^ That is correct!
-bash-4.2# curl -s ipinfo.io/ip
24.xxx.xxx.xxx # censored
-bash-4.2# # ^ That is *not* correct. Host is not facing public internet.

Do you think my suggestion (of having a client-side SSH wrapper) would fix the AWS problem? Because that way, iTerm knows exactly the hostname that the user SSHed to.

Awesome, thanks for the info! A couple of follow-ups question to see if I can make a temp fix for you.

One quick test I forgot to ask the first time:

can you run uname -n (on OpenBSD) and post the results?

Possible Solution 1 - mDNS:

Do you know if you have mDNS support installed? Try typing ping bigbox.local (or ssh user@bigbox.local) from your Mac, and see if you OpenBSD host responds.
If so, then one of my fixes for issue #4194 will allow you to connect to you host. It works by appending ".local" to the hostname so that the SCP commands and auto-profile switching work for non-DNS hosts.
This is part of "zero config networking" and is default behavior in non-DNS environments on most current Linux distros & OSX (not sure about OpenBSD). On Linux, it's usually enabled by a package called Avahi, which also exists for OpenBSD.
If your OpenBSD host doesn't have it installed by default, and you want to experiment: you can try installing Avahi from the OpenBSD ports collection. (the command is probably pkg_add -v -i Avahi, but I'm not positive as I can't test it.)
If ".local" successfully resolves for you, I can probably send a temporary fix by way of some text to add to the "iterm shell integration script" (it depends on what shell you are using).

Method 2 - reading the SSH destination IP address:

The SSH_CONNECTION var gave us the IP Address we needed to connect to the host. Which means as a temporary fix, we could assign that IP to the variable iTerm uses for the hostname.
~~But, SSH_CONNECTION is a BASH environment variable and I'm unsure if there is an equivalent for other shells.~~ (corrected as per @gnachman below)
What shell do you normally use on OpenBSD? If it's not BASH, I'll have to research our options.
If it is BASH, I can send you a temporary fix by way of some text to add to the "iterm shell integration script"

SSH Wrapper

Thanks for your suggestion on this.
The AWS problem is very unique as neither the hostname, nor IP addresses stay the same when hosts are restarted. I use a script before connecting to query AWS (using an InstanceID) to get the host URL. But I'm not sure there's much more that can be done until some more functionality is added into iTerm's auto-profile switching logic (as I need the ability to query on an a custom, user-set "InstanceID" variable).
Regarding using it to address the other connectivity challenges, I'm probably not the correct person to comment as I don't own the project or have to support it. So i will defer to George.

Let me know the results of these tests, and I'll followup as appropriate.

@robertpeteuil SSH_CONNECTION is set by OpenSSH, not by bash. It's in the man page for ssh(1) on Mac OS.

Regarding the SSH wrapper, the main difficulty is getting the value passed to the host. You can't pass an environment variable over ssh without a host-side config change. You could print the RemoteHost escape sequence a single time prior to connecting, but when it disconnects you have no way of knowing what your current hostname is, so you're stuck.

@gnachman excellent find about the origins of SSH_CONNECTION! It's good to know this could be used on other shells if the destination IP is needed.

-bash-4.2# uname -n
bigbox

: ssh root@bigbox.local
ssh: Could not resolve hostname bigbox.local: nodename nor servname provided, or not known

Same after installing avahi.

The default OpenBSD shell is ksh. I just saw that bash was supported so I switched to it. No rush on the fix, I'm not blocking on this or anything, but I'll test something if you want me to.

I use a script before connecting to query AWS (using an InstanceID) to get the host URL.

Does the script call SSH? If so, I think my suggestion would still work.

You could print the RemoteHost escape sequence a single time prior to connecting, but when it disconnects you have no way of knowing what your current hostname is, so you're stuck.

Could the wrapper script not print the escape sequence after ssh exits?

Thanks for the update, Will. Thanks for testing Avahi.

Let me see if I understand you situation enough to make a temporary fix for this specific problem:

Is it correct to summarize your situation as "a local host (machine or VM) that you normally connect to via an IP address rather than a hostname"?
To confirm the answer above - the IP address you normally use, is the one that's returned if run echo $SSH_CONNECTION | awk '{split($3, ary, /%/); print ary[1]}' on the remote host?
If this is indeed the case, I can probably create a script that you can temporarily use to identify your host by the IP address instead of a hostname. ~~My uncertainty comes from the fact that I don't know if the auto-profile hostname detection code will work with an IP address - but it may be worth a try.~~ (update: I've tested this and it works on my linux hosts)
Let me know if I have the correct understanding of your situation. If so, I'll post a "temp workaround" shell integration script that you can test. (A permanent fix will likely require some mods to the auto-profile switching code to support host identification by name OR IP address.)

Part two: Avahi tests

I'm surprised that HOSTNAME.local doesnt work with Avahi installed.
Are you sure that Avahi process is running? (it could require restarting the networking or even restarting the host - which i'm not sure if you can do.)
I apologize for not knowing more, I'm just unfamiliar with OpenBSD.

Let me know you thoughts, and I'll keep testing things on this end.

It's another box on my LAN, not a VM. But yeah, I usually connect via ssh root@192.168.x.x.

Yes, $SSH_CONNECTION contains the correct IP.

Ah, Avahi was not running. I had to add enable-dbus=no to /etc/avahi/avahi-daemon.conf. Now, ssh root@bigbox.local does work (where bigbox is the output of hostname and the contents of /etc/myname).

Thanks!

Thanks for testing this and sharing your results! In the short term, I can send you a "quick fix" replacement script that will allow "auto-profile switching" to work for your scenario your host. The downside, is that a piece of it will be hardcoded, so it won't be suitable for all OpenBSD scenarios (yet).

I'd like to understand how you'd like this "quickfix" to work. Please, let me know which workaround you'd prefer? (these are only for my "quick-fix" not the eventual real fix).

Method 1 - Set the hostname to HOSTNAME + ".local" ("bigbox.local" in your case). Then under settings-profiles-advanced-'automatic profile switching' you would specify hostnames with a ".local" suffix ("bigbox.local" in your case).
Method 1 caveats - This quick-fix version would work on any linux & OSX hosts, but limited to OpenBSD hosts that don't use DNS (like yours). (explanation why is below)
Method 2 - Set the hostname to the IP address (from SSH_CONNECTION). Then under settings-profiles-'advanced-automatic profile switching' you specify the IP address instead of the hostname.
Method 2 options - I can limit which platforms this occurs on. For example, it can be set to only occur on OpenBSD; and on other OS types, still use the actual hostname. If you like this option - let me know what platforms to set the hostname to the IP address?

Explanation of the different methods:

The 1st method is one purposed new fix for linux hosts that don't use DNS (like your BSD machine). The "general purpose" solution is limited to linux for now, as on it we can check the contents of dnsdomainname to see if the host has a domain value set, and if not append ".local". I haven't had time to research an equivalent solution to determine the "domain" status on OpenBSD yet; so right now (on OpenBSD), it has to append ".local" every-time or never. (I'll figure this out once I have time to research.)
The 1st method is a fix that will can be done rather quickly as it doesn't require any additional features to be added to the iTerm application. (only changes in the shell integration script.)
The 2nd method uses the IP address instead of domain-name. IF it's configured to do this "always", "never" or "by OS", it doesn't require changes in the iTerm application.
The ultimate goal is to implement this in a universally applicable way, and give users the option to specify the identification method in the profile pane (by hostname, private IP address, or public IP address). However, this fix will require adding changes to the iTerm app, and adding new functionality to iTerm's auto-profile-switching and the profile UI. Thus, it will take longer to get done.

Please let me know which method you would like me to use for the "quick-fix" and I'll post it accordingly.

The second method sounds cleaner and easier. No need for Avahi! I would go for that one.

Sure thing.

Here's an 'patched' shell integration script that set's the HOSTNAME on all OS's to the private IP address.

I've included it both in bash & zsh versions. To install this very specific patch -

first install the regular host-integration script from iterm-install shell integration menu item
That will adjust your .zshrc file and copy the original file from the website
Then, replace the `.term_shell_integration.zsh' file in your home directory with the one attached below
logout and log back in
you can manually test the hostname value the script returns by typing echo $iterm2_hostname (you should see your IP address)
then adjust the advanced section of your profile to use your IP address for auto-switching
I can also make a version of this that only changes the "hostname" variable to IP for Linxu & OpenBSD, and leave it as an actual hostname on OSX.

.iterm2_shell_integration.zsh

.iterm2_shell_integration.bash

I suppose all. Can't see a personal use case where it would hurt.

Note - it's likely that you will not want to install this modified script on your main workstation (the Mac you run iTerm on), as it wont be able to get an IP address and thus won't be able to change the profile back to "default" (if you want it to switch back to a default profile).

This is due to the fact that this modified script get's the IP address from the "target of SSH", and when you run terminal on a local host, you haven't SSH'd - and thus the IP value is null. I could add a check for a null value (for this exact scenario) and get the IP address a different way. But, this leads to other problems like machines with multiple IP addresses, etc, etc...

So in short - I suggest you limit your use of this script to hosts that you need IP host identification, and leave the default one installed on other machines.

Make sense?

What's the purpose of getting local IP address on localhost? For SCP to the main workstation?

Perhaps in the long run, it might make sense to have a few options for getting the IP, and iTerm2 just tries them in order until one works.

But yeah, what you said makes sense.

Fair point about the localhost IP being moot for SCP. I should have explained the use-case I was getting at when I mentioned this.

I was specifically thinking of when you use "profiles" to do things like change the tab color or add a badge to the session based based on the host that you're connected to.
This is great when you connect to a session and a "profile" is trigger for the new host (via IP in these modified scripts).
But, when the when that SSH session ends, you need a way to change (the colors/badge) back by having a "localhost" profile.
The potential problem with running these patched 'IP address' scripts (on your localhost) is that they wont return an IP, and therefore wont trigger a "localhost" profile.
Thus, keeping the colors/badge set to the last host connected to.

Regarding fetching the IP address multiple ways -

Yes, this is one of the features I'm requesting.
As far as I can tell - there's no catch-all method to identify hosts: some will need the internal IP (as used here), some will need the Public IP (as is the case with my AWS instances), and some will need the hostname.
Thus, my current thought is to have the script return all of those values, then allow the user to specify in the profile (for that host) which one to use as a trigger.

@robertpeteuil FYI, issue #4232 (closed) proposes keeping a stack of profiles so users won't need to worry about changing their profile back. This makes detecting localhost for APS less critical.

Agreed. Keeping the profiles "stacked" fixes switching back and also makes "re-identification" unnecessary in some other scenarios as well.

I'm impressed that you were able to implement that so quickly!

Small problem with shell integration host detection

Designs

Child items ...

Activity

Admin message

Admin message

Small problem with shell integration host detection

Activity