-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
Upterm rejecting all ssh connections #93
Comments
Same issue, me and my friend added authorised keys from eachother and it still didn't work |
Can you try again? I found some issue with the |
@owenthereal with the new 0.6.8 release I still see the same behavior. In one window:
And in another window:
(And I see the same behavior when I assign an explicit authorized keys file with |
Hmm...I could not reproduce this. Can you try the |
I personally can't connect, it just stays at infinite connection (0.6.8 version, 0.6.7 has the same thing rn)
last lines from the ssh connection output, and it just stays like that, never connects, then errors on
Also, how can i disable pubkey auth for upterm? it asks my key pass to authorise with it on host (almost like if i was connecting to myself), and i don't want pubkey auth, i just want to share it (or at least share it with password at max) |
Connecting to uptermd.upterm.dev with
Compare that to this connection to a
|
Did you press
|
I did, yes. If you don't press |
I finally can reproduce it. It happens when I don't have the key in the ssh-agent. I will see where the problem is, fix it and report back. It's likely a recent change that broke it |
Okay, the root of the issue is that since openssh 8.8 (2021-09-26), the host algorithm type
What happens is that you only have a rsa key in your
You can also put in your
I would strongly recommend you to upgrade all your ssh keys to Ed25519 because that's the most secured ssh algorithm that is recommended to use over others: https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54. I will leave this issue open until |
Thanks, that was it. Seems to be working fine now! |
Hi, I have followed the above but getting the same thing since tmate no longer works:
I still get the following:
Any other suggestions? |
I would recommend stopping using any RSA key with
|
Well where I was going with that was that following the instructions to support RSA still doesn't work and still produces an error whereas @larsks got it to work. |
This contains partial fixes to the ssh-rsa issue: * owenthereal/upterm.crypto@1baeb1c * owenthereal/upterm.crypto@5d542ad Ref: #93
used upterm v0.8.2 in Ubuntu 20.04 LTS. In target host the OpenSSH server was set up with default options. In client side Ed25519 key pair was generated without password. Public key was copied via ssh-copy-id command to target host with upterm, which is VirtualBox virtual machine (VM). Direct connecting via SSH works fine with same Ed25519 key. But not via uptermd.upterm.dev server.
Relevant part from ~/.upterm/upterm.log
Sometimes even cannot start connection with upterm server:
But when used OpenSSH 9.0 server in Arch-based EndeavourOS, then it worked! Could connect even from Ubuntu 20.04, where OpenSSH v8.2 client was used. Noticed, that when started upterm 0.8.2 in Ubuntu 20.04 (which has OpenSSH_8.2p1, OpenSSL 1.1.1f) then on first connection:
... and ~/.ssh/authorized_keys file got content: But when started upterm in EndeavourOS, where is OpenSSH_9.0p1, OpenSSL 1.1.1o, then on first connection:
... and ~/.ssh/authorized_keys file got content:
When tried to connect from Win11 (21H2, 22000.376), then on first connection (although connection did not succeed):
... and |
running the following command fixed the problem
(your machine needs to have an ssh key associated with it) |
I was trying to spin up my first upterm session; after running
upterm host -- bash
I am presented with the expected ssh session information, but when I attempt to connect to that session from another system, I get a "permission denied" error:I haven't included any
--authorized-key
argument in myupterm host
command so I expected any ssh client to be able to connect.The text was updated successfully, but these errors were encountered: