search

Eugeny / tabby

A terminal for a more modern age
https://tabby.sh
MIT License
59.37k stars 3.39k forks source link

[SSH] Remote rejected opening a shell channel: Error: Unable to request a pseudo-terminal #2002

Closed 459217974 closed 2 years ago

459217974 commented 4 years ago

when I connect to a jumpserver, I get this error: [SSH] Remote rejected opening a shell channel: Error: Unable to request a pseudo-terminal

Eugeny commented 4 years ago

Should be fixed in the just-released alpha 99

459217974 commented 4 years ago

emmm.... I'm using alpha 99 but get this error

Eugeny commented 4 years ago

Is it a "normal" Linux/UNIX machine or a network device? Can you connect to it using OpenSSH without the -T (don't allocate PTY) flag?

459217974 commented 4 years ago

It's not a "normal" Linux/UNIX machine, It's a jumpserver and it using the paramiko(python package) to simulate a terminal. when I using -T flag, I can not connect to the server. logs:

ssh someone@jumpserver.address.com -p 2222 -T -v                                                                                                                      someone@localhost
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/someone/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to jumpserver.address.com [10.18.0.94] port 2222.
debug1: Connection established.
debug1: identity file /Users/someone/.ssh/id_rsa type 0
debug1: identity file /Users/someone/.ssh/id_rsa-cert type -1
debug1: identity file /Users/someone/.ssh/id_dsa type -1
debug1: identity file /Users/someone/.ssh/id_dsa-cert type -1
debug1: identity file /Users/someone/.ssh/id_ecdsa type -1
debug1: identity file /Users/someone/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/someone/.ssh/id_ed25519 type -1
debug1: identity file /Users/someone/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/someone/.ssh/id_xmss type -1
debug1: identity file /Users/someone/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version paramiko_2.4.1
debug1: no match: paramiko_2.4.1
debug1: Authenticating to jumpserver.address.com:2222 as 'someone'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:2Z1ekqP2dKrrLQbQwTyox5xMk80fqPgu6J6WRFiWTeg
debug1: Host '[jumpserver.address.com]:2222' is known and matches the RSA host key.
debug1: Found key in /Users/someone/.ssh/known_hosts:4
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: Will attempt key: /Users/someone/.ssh/id_rsa RSA SHA256:h361ANBt9D1tBCNROOANlucHohfXReWhsalPkxB9Xgs
debug1: Will attempt key: /Users/someone/.ssh/id_dsa 
debug1: Will attempt key: /Users/someone/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/someone/.ssh/id_ed25519 
debug1: Will attempt key: /Users/someone/.ssh/id_xmss 
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/someone/.ssh/id_rsa RSA SHA256:h361ANBt9D1tBCNROOANlucHohfXReWhsalPkxB9Xgs
debug1: Server accepts key: /Users/someone/.ssh/id_rsa RSA SHA256:h361ANBt9D1tBCNROOANlucHohfXReWhsalPkxB9Xgs
debug1: Authentication succeeded (publickey).
Authenticated to jumpserver.address.com ([10.18.0.94]:2222).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_ALL = en_US.UTF-8
debug1: Sending env LC_MESSAGES = en_US.UTF-8
debug1: Sending env LC_NUMERIC = en_US.UTF-8
debug1: Sending env LC_COLLATE = en_US.UTF-8
debug1: Sending env LC_MONETARY = en_US.UTF-8
debug1: channel 0: free: client-session, nchannels 1
Connection to jumpserver.address.com closed by remote host.
Transferred: sent 3024, received 1696 bytes, in 5.0 seconds
Bytes per second: sent 604.2, received 338.9
debug1: Exit status -1

and without -T flag:

ssh someone@jumpserver.address.com -p 2222 -v                                                                                                                         someone@localhost
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/someone/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to jumpserver.address.com [10.18.0.94] port 2222.
debug1: Connection established.
debug1: identity file /Users/someone/.ssh/id_rsa type 0
debug1: identity file /Users/someone/.ssh/id_rsa-cert type -1
debug1: identity file /Users/someone/.ssh/id_dsa type -1
debug1: identity file /Users/someone/.ssh/id_dsa-cert type -1
debug1: identity file /Users/someone/.ssh/id_ecdsa type -1
debug1: identity file /Users/someone/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/someone/.ssh/id_ed25519 type -1
debug1: identity file /Users/someone/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/someone/.ssh/id_xmss type -1
debug1: identity file /Users/someone/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version paramiko_2.4.1
debug1: no match: paramiko_2.4.1
debug1: Authenticating to jumpserver.address.com:2222 as 'someone'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:2Z1ekqP2dKrrLQbQwTyox5xMk80fqPgu6J6WRFiWTeg
debug1: Host '[jumpserver.address.com]:2222' is known and matches the RSA host key.
debug1: Found key in /Users/someone/.ssh/known_hosts:4
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: Will attempt key: /Users/someone/.ssh/id_rsa RSA SHA256:h361ANBt9D1tBCNROOANlucHohfXReWhsalPkxB9Xgs
debug1: Will attempt key: /Users/someone/.ssh/id_dsa 
debug1: Will attempt key: /Users/someone/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/someone/.ssh/id_ed25519 
debug1: Will attempt key: /Users/someone/.ssh/id_xmss 
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/someone/.ssh/id_rsa RSA SHA256:h361ANBt9D1tBCNROOANlucHohfXReWhsalPkxB9Xgs
debug1: Server accepts key: /Users/someone/.ssh/id_rsa RSA SHA256:h361ANBt9D1tBCNROOANlucHohfXReWhsalPkxB9Xgs
debug1: Authentication succeeded (publickey).
Authenticated to jumpserver.address.com ([10.18.0.94]:2222).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_ALL = en_US.UTF-8
debug1: Sending env LC_MESSAGES = en_US.UTF-8
debug1: Sending env LC_NUMERIC = en_US.UTF-8
debug1: Sending env LC_COLLATE = en_US.UTF-8
debug1: Sending env LC_MONETARY = en_US.UTF-8

and then connect succeed.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks unless you comment. Thank you for your contributions.

BenitzCoding commented 2 years ago

I'm having that issue. ;-;

Issues-translate-bot commented 2 years ago

The translator bot has detected that this issue body's language is not English, and has translated it automatically.

I'm having that issue. ;-;

antvig commented 2 years ago

Hi ! Also having the issue when trying to connect to a standard linux remote machine.

in bash ssh root@000.000.000.00 works fine but with a SSH connexion, I have the error : 

 SSH  Loading private key: file://C:\Users\ant\.ssh\id_rsa
 X  All configured authentication methods failed
 SSH   X  Remote rejected opening a shell channel: Error: Not connected
boxker commented 2 years ago

I'm having that issue. ;-;

b10c77 commented 2 years ago

Having the issue as well, can this be when using an external private key file?

EDIT: it's probably because I'm using the file in PEM format

anzepintar commented 2 years ago

I am having this issue too. It gives me this error in tabby, but works fine in putty.

0xfurtrash commented 2 years ago

I'm having this issue as well. MobaXTerm connects fine with the same IP, Private key, port, and everything. Doesn't work in Tabby.

SSH X Remote rejected opening a shell channel: Error: Not connected

anzepintar commented 2 years ago

I managed to get it working for me by generating my key in ed255519 ssh-keygen -t ed25519 -C "your@email.address" and generating it with password.

Gypsying commented 2 years ago

I'm having this issue as well.... Any methods to solve this issue?

459217974 commented 2 years ago

@Eugeny Can you reopen this issue? It seems that many people still encounter this issue. Opening this issue can get more attention. Maybe this problem can be fixed.

accountnujen commented 2 years ago

точно такая же ошибка на ubuntu 22. Termius запускается без ошибки.

I managed to get it working for me by generating my key in ed255519 ssh-keygen -t ed25519 -C "your@email.address" and generating it with password.

I tried to do that, but it didn't work.

accountnujen commented 2 years ago

я проверил. Дело в версии ОС. Если на сервер поставить Ubuntu 22, то будет ошибка, а на версии Ubuntu 20 такой ошибки нет. Возможно, это проблема в каком-то сертификате, который истёк.

Issues-translate-bot commented 2 years ago

The translator bot has detected that this issue body's language is not English, and has translated it automatically.

I checked. It's the OS version. If you put Ubuntu 22 on the server, then there will be an error, but there is no such error on the Ubuntu 20 version. Perhaps this is a problem in some certificate that has expired.

anzepintar commented 2 years ago

‎I‎ проверил. Дело в версии ОС. Если на сервер поставить Ubuntu 22, то будет ошибка, а на версии Ubuntu 20 такой ошибки нет. Возможно, это проблема в каком-то сертификате, который истёк.

It works fine for me on Ubuntu 22.04

Issues-translate-bot commented 2 years ago

The translator bot has detected that this issue body's language is not English, and has translated it automatically.

‎I‎ checked. It's the OS version. If you put Ubuntu 22 on the server, then there will be an error, but there is no such error on the Ubuntu 20 version. Perhaps this is a problem in some certificate that has expired.

It works fine for me on Ubuntu 22.04

smutao commented 2 years ago

The translator bot has detected that this issue body's language is not English, and has translated it automatically.

I checked. It's the OS version. If you put Ubuntu 22 on the server, then there will be an error, but there is no such error on the Ubuntu 20 version. Perhaps this is a problem in some certificate that has expired.

having the same issue here with ubuntu 22.04 on server

cayenne17 commented 2 years ago

I have the same problem on a ubuntu 22.04 server I added the line in the file /etc/ssh/sshd_config on the server: PubkeyAcceptedAlgorithms +ssh-rsa I restarted the sshd service and now it works

cayenne17 commented 2 years ago

I have the same problem on a ubuntu 22.04 server I added the line in the file /etc/ssh/sshd_config on the server: PubkeyAcceptedAlgorithms +ssh-rsa I restarted the sshd service and now it works

On the server, I just tried to put back the config file /etc/ssh/sshd_config as it was. On the tabby client, I then checked only rsa-sha2-256 and rsa-sha2-512 in host key :

image

On tabby, I always get the error message: image

On the server, in the file /var/log/auth.log, I have the message: image

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

while I have disabled ssh-rsa on the SSH tabby client

Eugeny commented 2 years ago

@cayenne17 that algorithm list refers to host keys, i.e. the server authenticating itself to the client.

Eugeny commented 2 years ago

Duplicate of #6804

YEZI-HX commented 2 years ago

I'm having that issue. ;-;Windows Server2019

Dan-Essin commented 2 years ago

It's happening to me in 183 ssh from windows cmd.exe works fine

felixf4xu commented 2 years ago

v1.0.183 same issue.

ssh from ubuntu 20 to ubuntu 18.

it fails only when I connect to remote ssh via "Profile and Connection" dialog. If I open a local terminal inside tabby and type ssh name@host and press enter to log in, it works and can connect to host.

RavenKong commented 2 years ago

still happens in v.1.0.183. Issue seems happen when duplicate a connection which already connected ( that connection has establish some port forwarding tunnel through a jump host). If I disconnect the existing connection, and reconnect, no issue. Only happens when duplicating establish connexion.

Tested from windows client to a remote server through a jump host (bastion) No issue tests with Putty/Kitty with same port fowarded and duplicating more connections.

winkelement commented 2 years ago

I can confirm creating ssh connections via "Profile and Connection" dialog is broken for a while now. Connecting via CLI normally works just fine.

NetAssisson commented 1 year ago

still happens in v.1.0.187. I developed a virtual host Centos7 using VMware. When I first connect, there is only one network adapter. In bash ssh@xxx.xxx.xxx.xxx works fine and on tabby works fine. When I add a network adapter to the Centos7, The bash ssh@xxx.xxx.xxx.xxx works fine but on tabby, the connection was slow and I got an error. X Timed out while waiting for handshake Miraculously, when I delete the newly created network adapter, the connection in tabby is back to normal.

shbearly commented 1 year ago

it has this issue in 1.0.184. after restart of tabby, no issues. All is good. But later(after several days), it's not able to add/duplicatae new session. I need to open almost 10 ssh with same server. Existing session are not impacted.

It should be a logic issue, I believe. If it's a cert issue, it should happen all the time highly possiblly.

I got the issue point: when I create more than 10 connectio with same server. It will reject me. The 11th will be rejected.

bendhu commented 6 months ago

Is this resolved? I am using the latest V1.0.207 still having this issue.