The error message is the client telling you that DES isn't a supported
cipher. That's not an issue with anyone's SSH as you seem to suggest?
it's the client telling you that a choice that's outside the protocol
spec can't be accepted.
Thus far the evidence is that you're working backwards from a poorly
designed client and mistakenly placing the blame on the server. I
restate this: any client that requires you to specify the cipher is
broken by design: instead of having the client and server decide
what's best out of what they support, the decision is instead left to
the user. You may upgrade each side and have far better choices than
what might work currently based on settings chosen from previous
capabilities, but you don't use those choices because upgrading the
level of crypto used has been left to the user. Furthermore, I believe
that the list of ciphers it presents isn't a correct enumeration for
the ssh client on the Mac, which isn't predominated by CBC ciphers. If
your extrapolation from the difficulty of this mode of operation is
that the server is broken, you're unfortunately strongly supporting
the contention that your client has been poorly designed because
you've been asked to make a choice and given nothing like adequate
information from the program to understand the consequences. It's bad
to require manual selection in the first place, and it doesn't say
anything in favour of the software that it it gives you choices that
it should know are a protocol/cipher combination explicitly outside of
the spec (see below for the relevant quote from the RFC, as well as
quotes from the ssh man pages). I use iTerm to invoke ssh directly,
which gives the same kind of bookmarking functionality Jellyfissh
touts without the broken business of trying to manage cipher
selection. I have a mixed network of various *nix implementations, and
I've never had the need to tweak cipher settings or seen any problems
in interoperability, whether for what Sun ships in OpenSolaris or
anything else. I really don't get why you think it's reasonable to
argue against this experience that you don't need to think about your
client as the problem or otherwise have any basis for claiming that
the OpenSolaris ssh is broken.
Now, if you won't get debug on the negotiation and you're not willing
to try ssh with the default client shipped with OS X, which I can
assure you does work without modification, how else do propose to
solve this problem (complaining about what Sun ships doesn't count)?
Have you looked for log entries in /var/log or /var/adm to see if sshd
gives adequate logging even without debug mode?
If you're really in doubt as to whether DES is going to work with
sshv2, have a look at the RFC, which says that even 3DES is considered
a legacy cipher for support in sshv2, as the cipher has an effective
key length of 112 bits, whereas the protocol is specified to require
at least 128-bit crypto. From RFC4253:
The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
encrypt), where the first 8 bytes of the key are used for the first
encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption. This requires 24 bytes of key data
(of which 168 bits are actually used). To implement CBC mode, outer
chaining MUST be used (i.e., there is only one initialization
vector). This is a block cipher with 8-byte blocks. This algorithm
is defined in [FIPS-46-3]. Note that since this algorithm only has an
effective key length of 112 bits ([SCHNEIER]), it does not meet the
specifications that SSH encryption algorithms should use keys of 128
bits or more. However, this algorithm is still REQUIRED for
historical reasons; essentially, all known implementations at the time
of this writing support this algorithm, and it is commonly used
because it is the fundamental interoperable algorithm. At some future
time, it is expected that another algorithm, one with better strength,
will become so prevalent and ubiquitous that the use of "3des-cbc"
will be deprecated by another STANDARDS ACTION.
Or you could just take the OS X ssh man pages as sufficiently
authoritative:
-c cipher_spec
Selects the cipher specification for encrypting the
session.
Protocol version 1 allows specification of a single
cipher. The supported values are ``3des'',
``blowfish'', and ``des''. 3des (triple-des) is an
encrypt-decrypt-encrypt triple with three
different keys. It is believed to be secure. blowfish
is a fast block cipher; it appears very
secure and is much faster than 3des. des is only
supported in the ssh client for interoper-
ability with legacy protocol 1 implementations that do
not support the 3des cipher. Its use is
strongly discouraged due to cryptographic weaknesses.
The default is ``3des''.
For protocol version 2, cipher_spec is a comma-separated
list of ciphers listed in order of
preference. The supported ciphers are: 3des-cbc, aes128-
cbc, aes192-cbc, aes256-cbc,
aes128-ctr, aes192-ctr, aes256-ctr, arcfour128,
arcfour256, arcfour, blowfish-cbc, and
cast128-cbc. The default is:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,
arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
aes192-ctr,aes256-ctr
As for giving a list with a preponderance of CBC options, the
OpenSolaris man page for ssh_config makes the following point:
While CBC modes are not considered as secure as other
modes in connection with the SSH protocol 2 they are
present at the back of the default client cipher list
for backward compatibility with SSH servers that do not
support other cipher modes.
and more to the point in sshd_config:
Using CBC modes on the server side is not recommended
due to potential security issues in connection with the
SSH protocol version 2.
I wouldn't complain about that.
Am 7 Feb 2010 um 17:59 schrieb Thomas Burgess:
> <a target='_blank' title='ImageShack - Image And Video Hosting'
> href='http://img215.imageshack.us/i/picture12am.png/'>
> <img src='http://img215.imageshack.us/i/picture12am.png/' border='0'/
> ></a>
>
> I assure you it is ssh2 and is set for des. normally 3des is the
> default. none of the other available Ciphers work, when i tried to
> edit the config file and restart ssh it crashed, went into
> maintainence mode and refused to start. Not sure if the Ciphers
> line has to go at a specific spot in the config or not...but it gave
> me trouble when i put it at the end.
>
> When i DO connect, it DOESN'T seem to ACTUALLY use des, because i
> get this error/warning
>
> No valid ciphers for protocol version 2 given, using defaults.
>
>
> This is quite annoying, why does SunSSH ship like this?
>
> I'd really appreciate a valid config which can use any of the follow
> from this screenshot:
> <a target='_blank' title='ImageShack - Image And Video Hosting'
> href='http://img5.imageshack.us/i/picture13gg.png/'><img
> src='http://img5.imageshack.us/img5/3070/picture13gg.png'
> border='0'/></a>
>
> On Sun, Feb 7, 2010 at 12:46 PM, Bayard Bell <buffer.g.overflow at
> googlemail.com
> > wrote:
> You shouldn't be able to use des at all if you're using v2 of the
> protocol. Perhaps the problem isn't your choice of ciphers but using
> ssh v1 or setting ciphers for the wrong version?
>
> Using iTerm allows you to use the native ssh client so that you
> don't have to fiddle with these settings in an alternate client
> that's glued in directly with the terminal client. I'd be concerned
> if it's showing you CBC cipher variants if it's not showing you the
> non-CBC versions or not warning you to use these only with a server
> that doesn't give you better choices, and I'd think that a client
> that's asking you to make these kinds of manual selections is more
> than a little broken, minimally at the design level. I use iTerm
> with the native ssh to access OpenSolaris, and I've never had to
> change the ciphers on either end from defaults.
>
> I believe ssh -vvv <hostname> on the client side will show you more
> of the crypto negotiation to assist you in debugging, while you can
> run sshd -ddd to get the server-side debug.
>
> Am 7 Feb 2010 um 16:22 schrieb Thomas Burgess:
>
> I normally use JellyFiSSH as my ssh tool on osx, and with every
> other os, it has no problems with any of the ssh encryption
> protocols. The default is 3des but it has many to chose from
> (blowfish, 3des-cbc, cast128-cbc, blowfish-cbc, arcfour, aes256-cbc)
>
> OpenSolaris doesn't allow me to use ANY of these, the only ciper i
> can chose is des, but when i actually connect i get this (error/
> warning?)
>
>
> No valid ciphers for protocol version 2 given, using defaults.
>
> how do i fix this?
>
> i looked in the config but it all looks correct
> --
> This message posted from opensolaris.org
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/security-discuss/attachments/20100207/e72c863d/attachment.html>
