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

Update to 0.7.x - Unable to SSH to Machines #476

Closed
oliv10 opened this issue Mar 19, 2024 · 21 comments
Closed

Update to 0.7.x - Unable to SSH to Machines #476

oliv10 opened this issue Mar 19, 2024 · 21 comments
Assignees
Labels
bug Something isn't working legacy Issue pertaining to WaveLegacy

Comments

@oliv10
Copy link

oliv10 commented Mar 19, 2024

Describe the bug
Unable to ssh into any machine. Reverting to an older version allows the application to SSH into other machines without issue.

To Reproduce
Steps to reproduce the behavior:
Update to version 0.7.x from 0.6.x

Expected behavior
ssh to work correctly.

Screenshots
If applicable, add screenshots to help explain your problem.

Screenshot 2024-03-19 at 10 12 37 AM Screenshot 2024-03-19 at 10 18 20 AM

Desktop (please complete the following information):

  • OS: MacOS M1 Max
  • Version 0.7.1

Additional context
Valid ssh sessions with no changes to my known_hosts file.

Clearing the known_hosts file did not make any changes to this issue.

Screenshot 2024-03-19 at 10 20 00 AM
Screenshot 2024-03-19 at 10 20 16 AM
@sawka sawka added the bug Something isn't working label Mar 20, 2024
@oneirocosm
Copy link
Member

oneirocosm commented Mar 20, 2024

Interesting--I would have expected clearing the known_hosts to at least temporarily make it go away. I'm really hoping it isn't an underlying bug in the library we're using. In the meantime, there are a few other things we could look at.

Which keywords are you using for this connection in your ssh_config file? You don't need to tell me anything like user and/or hostname, but it's possible there are more obscure ones that we don't support yet.

If you take a look at the known_hosts file, could you check what type of key is causing the error? (It should say before the key itself)

@stheil15
Copy link

Same here after an update but different error. Ubuntu 22.04

prompt> error, invalid packet received from waveshell client: raw[which: no mshell-v0.5 in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/stheil/.mshell)]

@oliv10
Copy link
Author

oliv10 commented Mar 20, 2024

@oneirocosm

Interesting--I would have expected clearing the known_hosts to at least temporarily make it go away. I'm really hoping it isn't an underlying bug in the library we're using. In the meantime, there are a few other things we could look at.

Clearning the known hosts does make it go away, I typed that sentence then testing it again for sanity's sake (forgot to update the sentence), and it did solve the issue. But it was kinda hit or miss with if it worked or not because the first time it did not fix it, which is very strange to me.

Which keywords are you using for this connection in your ssh_config file? You don't need to tell me anything like user and/or hostname, but it's possible there are more obscure ones that we don't support yet.

Nothing that the 0.6.x version didn't support. I am truly unsure what caused the issue to arise all of the sudden.

@oliv10
Copy link
Author

oliv10 commented Mar 20, 2024

Screenshot 2024-03-20 at 12 03 18 PM

After removing the offending lines (one of which was the machine I am attempting to connect to) from the known hosts file it then throws this error. Below are the types of keys that it was angry at.

Screenshot 2024-03-20 at 12 03 26 PM

@oneirocosm
Copy link
Member

@stheil15

Same here after an update but different error. Ubuntu 22.04

prompt> error, invalid packet received from waveshell client: raw[which: no mshell-v0.5 in > (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/stheil/.mshell)]

This looks like a separate issue that I've seen in development builds but not in production. You may be able to get around it by explicitly clicking the reinstall button and waiting a few minutes. (We unfortunately don't have a good install indicator when this happens).

@oneirocosm
Copy link
Member

oneirocosm commented Mar 20, 2024

@oliv10

Nothing that the 0.6.x version didn't support. I am truly unsure what caused the issue to arise all of the sudden.

We made a bunch of ssh changes in this update. Rather than using a text-based system with the regular ssh command, we're now using golang's x/crypto/ssh library. So there's a chance that these updates broke something that worked in the previous version. I imagine things like HashKnownHosts and FingerprintHash could cause some problems until more support is added.

@oneirocosm
Copy link
Member

oneirocosm commented Mar 20, 2024

Granted, none of that directly fixes your issue. Did you by chance get a popup with the remote host identification has changed error? Typically that would mean, that waveterm is finding a different entry in ~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/known_hosts, or /etc/ssh/known_hosts2 for that connection, but the credentials from that file don't match what is being received. But I would expect that you'd also see this when connecting with a regular ssh command as well.

@oliv10
Copy link
Author

oliv10 commented Mar 20, 2024

I am getting the remote host identification has changed error. However, when I ssh into the machine using my standard terminal it works just fine without issue. No other known_hosts files exist on my system either.

@oneirocosm
Copy link
Member

Would you happen to have two entries for the same remote in your known_hosts file but with different keys?

@oneirocosm
Copy link
Member

If so, it could be related to this bug golang/go#36126

@oliv10
Copy link
Author

oliv10 commented Mar 21, 2024

Would you happen to have two entries for the same remote in your known_hosts file but with different keys?

Not after removing the three keys it was mad about.

After wiping the known_hosts in its entirety and ssh into it using my normal terminal, it creates three known hosts for it using three different key types. So, I don't think that should be an issue anyway.

@oneirocosm
Copy link
Member

oneirocosm commented Mar 21, 2024

If it is creating the three known hosts entries, it likely does come from the bug I linked above. It seems like the library we're using can't handle being provided multiple key types. There is a PR to fix it, but it looks like it hasn't been touched in a while. Worst case scenario, we might be able to fork the library and implement the fix ourselves—at least until it gets merged into the original library.

@oliv10
Copy link
Author

oliv10 commented Mar 21, 2024

Well, its not. Cause with the known_hosts file having just those three keys that it generated from ssh into it using the standard terminal. Switching back to Wave with just those created worked perfectly fine.

@oliv10
Copy link
Author

oliv10 commented Mar 21, 2024

Screenshot 2024-03-20 at 9 47 45 PM

known_hosts file

Screenshot 2024-03-20 at 9 48 40 PM

Connection alive and happy, sans a few unrelated errors.

@oliv10
Copy link
Author

oliv10 commented Mar 21, 2024

Screenshot 2024-03-20 at 9 49 54 PM

Executes commands as it would through any other terminal

@oneirocosm
Copy link
Member

Oh good—I'm glad you have a workaround! Still, that means that we aren't writing to known_hosts properly. If you noticed any glaring differences (that don't require you to post your keys) between the known_hosts we produced and the known_hosts ssh produced, that would be helpful!

@oliv10
Copy link
Author

oliv10 commented Mar 22, 2024

Oh good—I'm glad you have a workaround! Still, that means that we aren't writing to known_hosts properly. If you noticed any glaring differences (that don't require you to post your keys) between the known_hosts we produced and the known_hosts ssh produced, that would be helpful!

With the known_hosts empty and trying to connect using wave it wouldn't prompt me to create the new keys at all. So I would say that's probably the first thing to take a look at.

@psgandalf
Copy link

I have the same problems. Ubuntu machines. It seams like there isn't any new line after the key is added to known_hosts. So the first one is ok. When the second is added it just appends to the first one. Manually editing the row and press enter to force a newline makes everything correct again.

@oneirocosm
Copy link
Member

I see where the issue is now. And it shouldn't be too hard to fix, so it will be in our next release.

oneirocosm added a commit that referenced this issue Apr 18, 2024
This fixes issue #476 by ensuring that when waveterm writes to a
knownhosts file, a newline character is appended at the end.
sawka pushed a commit that referenced this issue Apr 18, 2024
This fixes issue #476 by ensuring that when waveterm writes to a
knownhosts file, a newline character is appended at the end.
@psgandalf
Copy link

a linux build confirmes that the fix is the solution to the problem.
Thx for the quick fix.

@oneirocosm
Copy link
Member

While this fixed part of this issue, it seems the initial issue still exists as referenced here golang/go#36126

Since that one is more active, I will close this one and continue to work on a fix there.

@esimkowitz esimkowitz added the legacy Issue pertaining to WaveLegacy label Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working legacy Issue pertaining to WaveLegacy
Projects
None yet
Development

No branches or pull requests

6 participants