New ssh/sshd patches for Solaris 9
Chris Thompson
112908-24 krb5, gss Patch
113273-11 /usr/lib/ssh/sshd Patch
114356-07 /usr/bin/ssh Patch
117177-02 lib/gss module Patch
on a couple of workstations. They can still ssh to each other, but while
doing so generate messages like
ssh[4690]: Kerberos mechanism library initialization error: No profile file open.
unable to initialize mechanism library [/usr/lib/gss/gl/mech_krb5.so]
unable to initialize mechanism library [/usr/lib/gss/gl/mech_krb5.so]
(and similar messages from sshd on the ssh'd-to workstation once it
has been rebooted and the new sshd is running). These hosts don't have
any Kerberos setup at all.
Anyone else seen this? or know how to fix it?
--
Chris Thompson
Email: cet1 [at] cam.ac.uk
Richard L. Hamilton
Just tried ssh'ing to myself after having put those on a day or so ago;
saw the same messages too. No idea what it means (yet). Commenting
out the kerberos_v5 line in /etc/gss/mech leads to a different error
message.
The code on opensolaris.org may be sufficient to get a better idea what
it means, however I'm not awake enough right now (or interested enough,
insofar as it's mostly a nuisance more than a critical problem) to attempt
that myself just now; which is to say that I didn't stumble into just what
it means at the first couple of places I looked, and it's involved enough
to find it that I'm not going to postpone much needed beauty sleep further,
lest I frighten every living creature nearby, get charged with vandalizing
traffic cameras, etc.
--
mailto:rlh...@smart.net http://www.smart.net/~rlhamil
Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"
DunTikoMoi
the same thing and is in need of a solution.
Chris Thompson
OK - an update including a circumvention which may even be the right fix.
Thanks to my colleagues locally for assistance, especially Steve Ison.
It seems that the problem arises if you started from a sufficiently
ancient Solaris 9 MU, and have been maintaining via patches since
then. The fix is to modify /etc/krb5/krb5.conf as follows:
1. comment out ___slave_kcds___ in the [realms] section
2. comment out ___domain_mapping___ in the [domain_realm] section
3. add "___domainname___ = ___default_realm___" in the latter
(actually, this third seems not to be neccesary)
Similar problems have arisen before in a different context, see:
http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-06/0632.html
The patches ought to fix /etc/krb5/krb5.conf themselves (or have
a prereq patch that does) of course.
--
Chris Thompson
University of Cambridge Computing Service
Email: cet1 [at] cam.ac.uk
Richard L. Hamilton
ce...@cus.cam.ac.uk (Chris Thompson) writes:
> In article <1225agp...@corp.supernews.com>,
> Richard L. Hamilton <Richard.L...@mindwarp.smart.net> wrote:
>>Just tried ssh'ing to myself after having put those on a day or so ago;
>>saw the same messages too. No idea what it means (yet). Commenting
>>out the kerberos_v5 line in /etc/gss/mech leads to a different error
>>message.
>>
>>The code on opensolaris.org may be sufficient to get a better idea what
>>it means, however I'm not awake enough right now (or interested enough,
>>insofar as it's mostly a nuisance more than a critical problem) to attempt
>>that myself just now; which is to say that I didn't stumble into just what
>>it means at the first couple of places I looked, and it's involved enough
>>to find it that I'm not going to postpone much needed beauty sleep further,
>>lest I frighten every living creature nearby, get charged with vandalizing
>>traffic cameras, etc.
>
> OK - an update including a circumvention which may even be the right fix.
> Thanks to my colleagues locally for assistance, especially Steve Ison.
>
> It seems that the problem arises if you started from a sufficiently
> ancient Solaris 9 MU, and have been maintaining via patches since
Ok, that's me.
> then. The fix is to modify /etc/krb5/krb5.conf as follows:
>
> 1. comment out ___slave_kcds___ in the [realms] section
> 2. comment out ___domain_mapping___ in the [domain_realm] section
> 3. add "___domainname___ = ___default_realm___" in the latter
> (actually, this third seems not to be neccesary)
>
> Similar problems have arisen before in a different context, see:
>
> http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-06/0632.html
>
> The patches ought to fix /etc/krb5/krb5.conf themselves (or have
> a prereq patch that does) of course.
>
Those changes (or even just the first two) get rid of the original error
messages. Now there's just one new one:
Mar 29 23:56:33 mindwarp sshd[13659]: Failed none for rlhamil from 192.168.1.6 port 48544 ssh2
although it connects fine after that.
Dave Uhring
> Those changes (or even just the first two) get rid of the original error
> messages. Now there's just one new one:
>
> Mar 29 23:56:33 mindwarp sshd[13659]: Failed none for rlhamil from
> 192.168.1.6 port 48544 ssh2
>
> although it connects fine after that.
Can your server inverse resolve the address 192.168.1.6? If not then
either add an entry into mindwarp:/etc/inet/hosts or fix your DNS.
Rob
> Chris Thompson
I've seen this plus a mallloc error.
unable to initialize mechanism library [/usr/lib/gss/gl/mech_krb5.so]
xmalloc: zero size
backing off 114356-07 fixed the problem.
dan
the same library initialization error. I have searched through the MIT
Kerberos website FAQ's and run google searches on several different
search strings including components from the error message. Through
all of that searching, I have only come across the
"http://unix.derkeiler.com" newsgroup email and this topic. I was
ecstatic to have found something related to our issue.
However, all of my excitement was flushed upon looking in our
/etc/krb5/krb5.conf file. The file looks as though someone has seen
this topic and updated the file as was suggested. Unfortunately, we
are still getting the error messages and am now back to the starting
point of not knowing what exactly is happening. If you have any other
suggestions, they would be greatly appreciated.
Thanks,
Dan
Rob
GSSAPIAuthentication=no
GSSAPIKeyExchange=no
if you are not using the GSSAPI features
to /etc/ssh/ssh_config and
/etc/ssh/sshd_config
Richard L. Hamilton
Fredrik Lundholm
Richard L. Hamilton <Richard.L...@mindwarp.smart.net> wrote:
>In article <e0ec0r$hs5$1...@gemini.csx.cam.ac.uk>,
> ce...@cus.cam.ac.uk (Chris Thompson) writes:
>> It seems that the problem arises if you started from a sufficiently
>> ancient Solaris 9 MU, and have been maintaining via patches since
>
>Ok, that's me.
Well I get the same problem using Solaris 9 9/05.
(the latest release)
--
Fredrik Lundholm
dol @ ce.chalmers.se
michell...@gmail.com
config file.
Thanks so much!
msb
encrypt...@yahoo.com
Facing same problem on Solaris 9 OS installed with latest patches.
SSH Version : Sun_SSH_1.0.1, protocol version 1.5/2.0
1. Tried creating my pubilc/private keys by:
#ssh-keygen -t dsa
2. cat id_dsa.pub >> authorized_keys
3. tried to ssh to a remote/local machine
got- unable to initialize mechanism library
[/usr/lib/gss/gl/mech_krb5.so]
4. removed patch 114356-07 and installed patch 114356-06, did not help
5. Whenever I try #ssh root@mac it asks for a password and when
supplied
with the right one does not accept it.
Output of #ssh -v root@mac
-----------------------------------------------------------------------------------------------------------------------------
bash-2.05# ssh -v root@mac
SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: ssh_connect: getuid 0 geteuid 0 anon 0
debug1: Connecting to sgw1 [10.132.197.198] port 22.
debug1: Allocated local port 1023.
debug1: Connection established.
debug1: identity file //.ssh/identity type 3
debug1: identity file //.ssh/id_rsa type 3
debug1: Bad RSA1 key file //.ssh/id_dsa.
debug1: identity file //.ssh/id_dsa type 3
debug1: Remote protocol version 2.0, remote software version
Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.0.1
debug1: sent kexinit: diffie-hellman-group1-sha1
debug1: sent kexinit: ssh-rsa,ssh-dss
debug1: sent kexinit: aes128-cbc,blowfish-cbc,3des-cbc,rijndael128-cbc
debug1: sent kexinit: aes128-cbc,blowfish-cbc,3des-cbc,rijndael128-cbc
debug1: sent kexinit: hmac-sha1,hmac-md5
debug1: sent kexinit: hmac-sha1,hmac-md5
debug1: sent kexinit: none
debug1: sent kexinit: none
debug1: sent kexinit:
debug1: sent kexinit:
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug1: got kexinit: ssh-rsa,ssh-dss
debug1: got kexinit: aes128-cbc,blowfish-cbc,3des-cbc
debug1: got kexinit: aes128-cbc,blowfish-cbc,3des-cbc
debug1: got kexinit: hmac-sha1,hmac-md5
debug1: got kexinit: hmac-sha1,hmac-md5
debug1: got kexinit: none,zlib
debug1: got kexinit: none,zlib
debug1: got kexinit: POSIX,C
debug1: got kexinit: POSIX,C
debug1: first kex follow: 0
debug1: reserved: 0
debug1: done
debug1: kex: server->client unable to decide common locale
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: kex: client->server unable to decide common locale
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug1: Sending SSH2_MSG_KEXDH_INIT.
debug1: bits set: 500/1024
debug1: Wait SSH2_MSG_KEXDH_REPLY.
debug1: Got SSH2_MSG_KEXDH_REPLY.
debug1: Host 'sgw1' is known and matches the RSA host key.
debug1: Found key in //.ssh/known_hosts:1
debug1: bits set: 495/1024
debug1: ssh_rsa_verify: signature correct
debug1: Wait SSH2_MSG_NEWKEYS.
debug1: GOT SSH2_MSG_NEWKEYS.
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: done: KEX2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue:
gssapi-keyex,gssapi-with-mic,publickey,keyboard-in
teractive
debug1: next auth method to try is publickey
debug1: key does not exist: //.ssh/identity
debug1: key does not exist: //.ssh/id_rsa
debug1: try pubkey: //.ssh/id_dsa
debug1: read SSH2 private key done: name dsa w/o comment success 1
debug1: sig size 20 20
debug1: authentications that can continue:
gssapi-keyex,gssapi-with-mic,publickey,keyboard-in
teractive
debug1: next auth method to try is publickey
debug1: next auth method to try is keyboard-interactive
Password:
-------------------------------------------------------------------------------------------------------------------------------
Output of /etc/ssh/sshd_config
------------------------------------------------------------------------
Protocol 2
Port 22
ListenAddress ::
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
KeepAlive yes
SyslogFacility auth
LogLevel info
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Ciphers aes128-cbc,blowfish-cbc,3des-cbc
MACS hmac-sha1,hmac-md5
ServerKeyBits 768
KeyRegenerationInterval 3600
StrictModes yes
LoginGraceTime 600
MaxAuthTries 6
MaxAuthTriesLog 3
PermitEmptyPasswords no
PasswordAuthentication yes
PAMAuthenticationViaKBDInt yes
PermitRootLogin no
Subsystem sftp /usr/lib/ssh/sftp-server
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
----------------------------------------------------------------------------------------------
Any ideas would be appreciated
RTE
Oscar del Rio
> 5. Whenever I try #ssh root@mac it asks for a password and when
> supplied with the right one does not accept it.
> Output of /etc/ssh/sshd_config
> PermitRootLogin no
.
encrypt...@yahoo.com
victorf...@yahoo.com
I had two errors and I got them resolved with the Sun's help
1.
xmalloc: zero size
2.
"unable to initialize mechanism library
[/usr/lib/gss/gl/mech_krb5.so]"
1.The xmalloc: zero size is a new bug (6402708)
A workaround. by inserting the following in
Your ssh_config file on both client and server
Workaround: inserting the following in
Your ssh_config file on both client and server
StrictHostKeyChecking no
2.For the "unable to initialize mechanism library
[/usr/lib/gss/gl/mech_krb5.so]" (see bug 6392328)
Workarounds
1)
Add to /etc/ssh/ssh_config and /etc/ssh/sshd_config:
GSSAPIAuthentication=no
GSSAPIKeyExchange=no
2) Replace /etc/krb5/krb5.conf with following
# Begining of the file
#
# ident "@(#)krb5.conf 1.4 05/06/08 SMI"
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name>__ placeholders
# with appropriate values for your network.
#
[libdefaults]
default_realm = ___default_realm___
[realms]
___default_realm___ = {
kdc = ___master_kdc___
admin_server = ___master_kdc___
}
[domain_realm]
___domainname___ = ___default_realm___
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1,
...)
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
# end of file
**Important..In order for new changes to take effect
you must restart sshd process after making your changes
Victor