Portserver TS 16 + OpenSSH >= 5.2


We are using a couple of Portserver TS 16’s to manage our Linux servers via the serial console. Since OpenSSH version 5.2 (client side) we are not able to connect to the device anymore.

When using OpenSSH with the -v option it all hangs after:

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received

We tested the following versions:

OpenSSH_5.1p1 / OpenSSL 0.9.8g: successful 
OpenSSH_5.1p1 / OpenSSL 0.9.8n: successful
OpenSSH_5.2p1 / OpenSSL 0.9.8n: [b]hangs[/b]
OpenSSH_5.3p1 / OpenSSL 0.9.8k: [b]hangs[/b]
OpenSSH_5.3p1 / OpenSSL 0.9.8n: [b]hangs[/b]
OpenSSH_5.5p1 / OpenSSL 0.9.8n: [b]hangs[/b]

Information about the devices:[ul]
[li]P/N: 50000854-01
[/li][li]POST: 82000685_G
[/li][li]Firmware: 82000684_U1
Is anyone familiar with this problem? And more important, is there a solution for this problem?

In testing here. I too see the same on:
OpenSSH_5.2p1, OpenSSL 0.9.8e

Four other SSH clients I tested work fine.

Please open a case with Digi Tech Support here:

I opened a case at Digi Tech Support. In the first reply from Digi:

Currently, there is no firmware availble for these products which support the newer versions of OpenSSH.
I’m now contacting our Sales Representative.

Four other SSH clients I tested work fine.
I’m very interested which clients worked fine? All < OpenSSH 5.2?

Four other SSH clients I tested work fine.

I’m very interested which clients worked fine? All < OpenSSH 5.2?

I tested a few windows apps that work: PuTTY, TeraTerm, and SecureCRT.

Has anyone looked at what changed on the OpenSSH side? Is there some new feature or crypto algorithm that we can disable in the OpenSSH client configuration (in the “.ssh/config” or an “-o” option) to work around this?

When comparing the “-v -v -v” output from a working and non-working OpenSSH, I thought it might have something to do with the new, undocumented “roaming” feature, but looking at the OpenSSH commit logs and trying with “UseRoaming no,” it doesn’t look like that’s the problem.

I have not been able to determine what exactly changed to break compatibility.

You should contact your Digi Sales Representative regarding this issue for possible alternatives.

You should contact your Digi Sales Representative regarding this issue for possible alternatives.

We’ve had contact with our Digi Sales Representative about 2 months ago. This was his answer:

this request was denied and canceled by our product management / engineering department

it mean that we don’t do it for now.
If you come back with a nice deal which would justify the implementation of it the we would do it.
But for now you have been the only customer who asked for this feature.
And our product management decided it not to do because they don’t see revenue behind.
In short, this product is incompatible with any recent Linux or BSD distribution. And there won’t be a solution unless we (or maybe someone) come(s) back with a nice deal!?

I’m sorry to say, but we are looking for other solutions now.

Digi’s new “Connectport LTS” product line supports the latest OpenSSH revs.

RedHat EL5 systems can no longer use SSH to access a PortServer TS system if the RedHat system has updated to openssh-4.3p2-72 or newer.

Since keeping systems patched up-to-date is a requirement on our government systems we can no longer access our PortServer TS 16 systems via SSH from our systems, all of which are running RedHat EL5. Soon most/all Linux distributions will be running newer versions of openssh and most/all Linux systems will be unable to connect to the PortServer TS using SSH.

I hope Digi releases updated firmware soon. The SSH feature is what attracted us to this product but now this feature effectively no longer exists.

Please contact your Digi Government Sales Representative to discuss this further:


After some head scratching this worked for me:

ssh -c aes256 root@wsdigi03
as did this
ssh -c 3des-cbc root@wsdigi03

OpenSSH_5.5p1 Debian-4ubuntu6, OpenSSL 0.9.8o 01 Jun 2010
My method of figuring this out:
>ssh -c aes256-ctr root@wsdigi03
no matching cipher found: client aes256-ctr server aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,cast128-cbc,arcfour

Thanks a lot gsker!
Your workaround works for me too.

Interesting is that all of the ciphers supported by the server work when you select them manually.

In my case when I don’t use the -c option, aes128-cbc will be selected automatically but hangs. When using -c aes128-cbc it doesn’t hang.