Hello and apologies if this isn't the appropriate venue for this post.
I encountered an unexpected failure in ssh at the end of a zone upgrade
scenario. Here's some background on the situation, the ssh failure itself will
described further on.
1. I initially had an OpenSolaris system installed with 2008.11. Let's call it
'donkeykong'.
2. I created a local zone named 'bowser' on that system. It's a sparse zone and
appears as an 'ipkg' branded zone in the output of zoneadm list:
---
$ zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
6 bowser running /export/zones/bowser ipkg shared
---
3. At this point in time, I could ssh into either donkeykong or bowser from an
other system (my desktop).
4. I halted the local zone and ran 'pkg image-update' on the global zone after
having set the preferred authority to the dev repository. Thereafter, I
rebooted into a snv_108 boot environment on donkeykong.
5. At this point, I was of course able to ssh into the global zone
6. From within the global zone, I manually mounted the new 'zbe' filesystem
onto /mnt and proceeded to run 'pkg -R /mnt/ image-update' to update the image
in the zone's filesystem.
7. I unmounted the 'zbe' filesystem and restarted the zone.
8. At this point, I was able to zlogin into the zone which would show:
---
root at bowser:~# pkg info SUNWsshd
Name: SUNWsshd
Summary: SSH Server
Category: System/Security
State: Installed
Authority: dev
Version: 0.5.11
Build Release: 5.11
Branch: 0.108
Packaging Date: Wed Feb 18 05:48:53 2009
Size: 937.12 kB
FMRI: pkg:/SUNWsshd at 0.5.11,5.11-0.108:20090218T054853Z
---
However, I was *not* able to ssh into that zone from my desktop. The ssh client
would abort with:
---
$ ssh bowser
Connection closed by XX.XX.XX.XX
---
I logged into the local zone through zconsole and ran sshd in the following
manner to get more debug output:
---
root at bowser:/usr/lib/ssh# /usr/lib/ssh/sshd -d -D
debug1: sshd version Sun_SSH_1.3
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
<at this point, sshd waits for an incoming connection>
debug1: Server will not fork when running in debugging mode.
Connection from 129.156.234.15 port 62317
debug1: Client protocol version 2.0; client software version Sun_SSH_1.2
debug1: match: Sun_SSH_1.2 pat Sun_SSH_1.2*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.3
monitor debug1: list_hostkey_types: ssh-rsa,ssh-dss
sh: line 1: /usr/bin/locale: not found
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and
symmetric ciphers
debug1: pkcs11 engine initialization complete
debug1: list_hostkey_types: ssh-rsa,ssh-dss
sh: line 1: /usr/bin/locale: not found
Segmentation Fault (core dumped)
---
It makes sense that sshd would complain about /usr/bin/locale since that file
didn't exist in the local zone at this point. Furthermore, after installing
SUNWloc -to which /usr/bin/locale belongs- I was able to ssh into the zone from
my desktop.
Now this raises the following questions:
1. I'm quite sure that /usr/bin/locale was not present in the local zone when
it was created from a 2008.11 install, yet I was able to ssh into it. Does that
mean that the move to snv_108 introduced a de facto dependency between ssh and
SUNWloc?
2. Assuming the answer to the previous question is 'yes', would it therefore be
justified to ensure that SUNWloc is installed on ipkg local zones, whether in a
new zone creation scenario or whilst upgrading the pkg image on a zone's zbe? I
found not being able to ssh into my local zone to be quite unpleasant and other
users may feel that way. This question is probably more relevant to the pkg and
zones people.
Thanks in advance for any feedback you may have wrt this issue and apologies if
security-discuss isn't the appropriate list for this.
- Matt Boyer
--
This message posted from opensolaris.org
