Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After ssh from macOS to NetBSD/OpenBSD host, logged out after first command #855

Open
mcornick opened this issue Dec 19, 2024 · 5 comments

Comments

@mcornick
Copy link

I like Rio so far, but I've run into a really bizarre issue connecting via ssh from macOS to NetBSD and OpenBSD hosts in a Rio terminal.

I've installed Rio 0.2.2 via Homebrew on my M2 MacBook Air running Sequoia 15.2. I'm using the Homebrew cask installation, although I'm seeing the same version with Homebrew's formula installation.

If I ssh to hosts running NetBSD or OpenBSD, I get my usual prompt and can enter one command (or even just press Return), but then I am immediately logged out. This only seems to happen on NetBSD and OpenBSD hosts, not on any FreeBSD, Linux, or macOS hosts that I've tried.

Example:

mcornick@macbook-air ~ % ssh -v meta.sdf.org
OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/mcornick/.ssh/config
debug1: /Users/mcornick/.ssh/config line 2: include ~/.ssh/config.d/* matched no files
debug1: /Users/mcornick/.ssh/config line 20: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to meta.sdf.org port 22.
debug1: Connection established.
debug1: identity file /Users/mcornick/.ssh/id_ed25519 type 3
debug1: identity file /Users/mcornick/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9
debug1: compat_banner: match: OpenSSH_9.9 pat OpenSSH* compat 0x04000000
debug1: Authenticating to meta.sdf.org:22 as 'mcornick'
debug1: load_hostkeys: fopen /Users/mcornick/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:ZjwbO7AU8rHJExYrmZS2LqGZ7WfdoELfMrF54W92PYA
debug1: load_hostkeys: fopen /Users/mcornick/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'meta.sdf.org' is known and matches the ED25519 host key.
debug1: Found key in /Users/mcornick/.ssh/known_hosts:56
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: Sending SSH2_MSG_EXT_INFO
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /Users/mcornick/.ssh/id_ed25519 ED25519 SHA256:j7rnVdxCp1WgOwBhzhGvY1R7T1l1eFrMpVJS/SMN/d0 explicit agent
debug1: Offering public key: /Users/mcornick/.ssh/id_ed25519 ED25519 SHA256:j7rnVdxCp1WgOwBhzhGvY1R7T1l1eFrMpVJS/SMN/d0 explicit agent
debug1: Server accepts key: /Users/mcornick/.ssh/id_ed25519 ED25519 SHA256:j7rnVdxCp1WgOwBhzhGvY1R7T1l1eFrMpVJS/SMN/d0 explicit agent
Authenticated to meta.sdf.org ([205.166.94.5]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: client_input_hostkeys: searching /Users/mcornick/.ssh/known_hosts for meta.sdf.org / (none)
debug1: client_input_hostkeys: searching /Users/mcornick/.ssh/known_hosts2 for meta.sdf.org / (none)
debug1: client_input_hostkeys: hostkeys file /Users/mcornick/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: host key found matching a different name/address, skipping UserKnownHostsFile update
debug1: Remote: /sdf/arpa/gm/m/mcornick/.ssh/authorized_keys:5: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /sdf/arpa/gm/m/mcornick/.ssh/authorized_keys:5: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: channel 0: setting env LC_ALL = "en_US.UTF-8"
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: pledge: agent
mcornick@iceland:~$ # enter anything here
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to meta.sdf.org closed.
Transferred: sent 6172, received 6200 bytes, in 4.3 seconds
Bytes per second: sent 1446.0, received 1452.5
debug1: Exit status -1
mcornick@macbook-air ~ %

I am not seeing this when doing the same ssh from a Windows 11 machine; the ssh connection stays connected after executing the first command. I don't have a Linux workstation to test with.

I don't think this is related to anything in my .bashrc/.bash_profile/etc. as I've tried with all of those files removed on the remote host, and still the issue persists. This also doesn't seem to be related to the $TERM setting; it happens whether I have $TERM set to xterm-256color (my usual default) or to rio (with the terminfo installed on the remote host.) Nor does it seem related to the shell running on the remote host; I've tried bash, zsh, and ksh, and all exhibit the same behavior.

I've tried on three different OpenBSD hosts and two different NetBSD hosts (the above example is from a NetBSD host) all with the same results.

This is a weird one and I'm not sure what else to try. Got any ideas? Thanks!

@mcornick
Copy link
Author

One other thing to add: my .bash_logout clears the screen on logout, but when this behavior happens, the screen is not cleared, suggesting some sort of abnormal exit of the shell.

@raphamorim
Copy link
Owner

Hey @mcornick thanks for the detailed issue, I appreciate it!

Maybe isn't the fix but do you have rio terminfo installed ssh-ed machine? https://raphamorim.io/rio/docs/frequently-asked-questions/#i-get-errors-about-the-terminal-being-unknown-or-opening-the-terminal-failing-or-functional-keys-like-arrow-keys-dont-work

@mcornick
Copy link
Author

Hi, yeah, I've uploaded the terminfo to the various machines I've tried, and that doesn't seem to help either. Very strange!

@raphamorim
Copy link
Owner

Thank you!! I will mark to take a look once I finish #851 🙏

@mcornick
Copy link
Author

I've found a workaround while this is investigated, which I'm sharing in case anyone else runs into this: Mosh does not show the immediate disconnect-after-first-command behavior described in this issue, and works well on the NetBSD and OpenBSD hosts I've tried. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants