I changed an ASA to only accept V2 connections and turned on SSH debugging, and this is what I see on the appliance:
SSH1: SSH client: IP = interface # = 2
SSH: host key initialised
SSH1: starting SSH control process
SSH1: Exchanging versions – SSH-2.0-Cisco-1.25

SSH1: send SSH message: outdata is NULL

server version string:SSH-2.0-Cisco-1.25SSH1: receive SSH message: 83 (83)
SSH1: client version is – SSH-2.0-SSH/BBSSH

client version string:SSH-2.0-SSH/BBSSHSSH1: begin server key generation
SSH1: complete server key generation, elapsed time = 1790 ms

SSH2 1: SSH2_MSG_KEXINIT sent
SSH2 1: SSH2_MSG_KEXINIT received
SSH2: kex: client->server 3des-cbc hmac-sha1 none
SSH2: kex: server->client 3des-cbc hmac-sha1 none
SSH2 0: hostkey algo not supported: client ssh-dss, server ssh-rsaSSH1: Session disconnected by SSH server – error 0×00 “Internal error”

I double-checked the version I was running (1.1.5.20) and noticed I was a bit behind, but after upgrading to the latest version (1.1.80), it seems to connect just fine. I’m not sure what changed between versions, but I don’t have to change anything on the Cisco devices and it’s working beautifully! Thanks for the follow-up comment, I had kinda forgotten about this app…

An SSH v2 configuration can be set up to disallow the default TripleDES/3DES cipher. Even though this is part of the standard, it is easily disabled by changing options in /etc/sshd_config.

Currently, BBSSH (and midpssh) supports only this encryption method for SSH v2 as it’s what is required for the SSHv2 spec. The SSHv2 spec lists several optional crypto methods — none of which are supported by BBSSH or midpssh at this time. This is something that will be changing as I complete the BB Crypto integration for 1.1.10 – which will resolve the problem you’re experiencing.

So the next question is – why would midpssh work, and not BBSSH? When you connect via SSHv1, the same limitations are not in place — the default ciphers are less often disabled; but even when they are midpssh has support for 3-4 additional ciphers under SSHv1.

I removed SSHv1 support from BBSSH in version 1.1.5. While many hosts still accept SSHv1, it is less secure -and so far nobody has reported any case where they’re required to use SSHv1. Hosts that accept v1 usually also accept and prefer v2. It’s become the de facto standard over the last several years. v1 is gradually getting phased out on the server side as well – OpenBSD and others have begun shipping with v1 disabled by default. (Previously v1 and v2 were both enabled.)

The problem it presents in this case is that when using BBSSH, you won’t be able to work around the unsupported cipher by using SSH v1.

In the very short term, it sounds like you’re best served by continuing with MidpSSH, because it has v1 support. Your other short-option would be to convince your server admins to enable TripleDES/3DES as a cipher type, but I expect they had their reasons for disabling it.

In the longer term, Blackberry Crypto integration will be completed within BBSSH over the next month or so. Once that release is completed, you’ll be able to use BBSSH to connect to v2 servers.

(It’s also worth mentioning that for most folks, this won’t be an issue — by default TripleDES is enabled in SSHv2 servers, and it is the standard encryption algorithm of SSH v2. )

Telnet seems to work fine through BES.

Derek – I’d love to get more details about your trouble.

Generation of new key is in the “upcoming features” list; though it does support importing of existing keys as of 1.1.4. As for the connection issues I would love to get more details about the issues you’re having. I do know that there are folks who have been using it successfully via BES and TCP both; however I’ve also been learning that each OS + device version has its own quirks.

For me, it doesn’t seem very functional, but it looks nice