On 3/27/06, James Carlson <[EMAIL PROTECTED]> wrote:
> Roland Mainz writes:
> > Beyond that point this issue it does not only affect Sun, it also
> > affects OpenSolaris and the related distributions which makes it a valid
> > email for this list.
>
> It's perhaps worth noting that the ssh in Solaris is deliberately
> "SunSSH." Though it is a derivative of OpenSSH, it's certainly not
> the same thing.
yeah ! I always wondered about that. When one uses openssh to ssh
into a stock fresh Solaris system ( sorry for all the adverbs ) I see
something like this :
$ ssh -2 -4 -e\^ -l dclarke -c aes256-cbc -v 192.168.35.123
OpenSSH_3.9p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /opt/csw/etc/ssh_config
debug1: Connecting to 192.168.35.123 [192.168.35.123] port 22.
debug1: Connection established.
debug1: identity file /export/home/dclarke/.ssh/id_rsa type -1
debug1: identity file /export/home/dclarke/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
no matching cipher found: client aes256-cbc server
aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
$
There .. see that ? The remote rev is "Sun_SSH_1.1" and not OpenSSH.
If I drop the cipher length to aes128-cbc then I see this :
$ ssh -2 -4 -e\^ -l dclarke -c aes128-cbc -v 192.168.35.123
OpenSSH_3.9p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /opt/csw/etc/ssh_config
debug1: Connecting to 192.168.35.123 [192.168.35.123] port 22.
debug1: Connection established.
debug1: identity file /export/home/dclarke/.ssh/id_rsa type -1
debug1: identity file /export/home/dclarke/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host '192.168.35.123 (192.168.35.123)' can't be established.
RSA key fingerprint is ae:55:7b:bd:c2:97:eb:0a:6f:98:ac:4e:25:8c:29:4b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.35.123' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /export/home/dclarke/.ssh/id_rsa
debug1: Trying private key: /export/home/dclarke/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Mon Mar 27 09:36:54 2006 from 192.168.35.137
Sun Microsystems Inc. SunOS 5.11 snv_35 October 2007
$ uptime
9:44am up 8:02, 2 users, load average: 0.01, 0.00, 0.00
$ cat /etc/release
Solaris Nevada snv_35 SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 06 March 2006
$
Although further edification can be had by reading README.altprivsep
in /usr/src/cmd/ssh
thus :
1. Introduction
Implementations of SSH servers require some degree of privilege in
order to function properly. Often such implementations retain such
privilege throughout normal operation even while users are logged
in. This means that vulnerabilities in the implementation of the
protocols can be exploited in such ways as to escalate the privilege
that would normally be accorded to mer-mortal users.
The OpenSSH team introduced support for "privilege separation" in
the OpenSSH ssh server some years ago to minimize the extent of
extant, undiscovered vulnerabilities in the OpenSSH server source
code. The basic concept is to have a multi-process server
implementation where one process, the "monitor" is privileged and
implements a smaller protocol than the ssh protocols, and thus is,
hopefully, less likely to sport exploitable security bugs.
The ssh team at Sun agrees with the basic OpenSSH privilege
separation concept, but disagrees with its design.
Here we present our alternative to the OpenSSH design. We begin
with the question of just what is "privilege" and follow on with an
analysis of the SSH protocols vis-a-vis privilege. Then we briefly
describe the OpenSSH model, followed by an exposition of our
alternative model.
.
.
.
its well worth the read.
Dennis
_______________________________________________
opensolaris-discuss mailing list
[email protected]
