Hi all,
I just pushed a change to master on illumos-joyent, smartos-live and
illumos-extra that removes SunSSH from SmartOS (and SDC) and replaces it
with a patched OpenSSH 7.1p1.
If all goes well, this will be in the next release (ie, not the release that
branched this week).
While there are some known behavioural differences (explained below), please
note that the vast majority of existing SunSSH configurations, keys and
plugins (such as smartlogin for SDC) will continue to work as they are.
This also includes RBAC, and PAM configurations -- the new daemon has been
patched to exhibit the same behaviour and use the same PAM service names as
the old SunSSH it replaces.
Important differences:
Default key fingerprint format
==============================
The default format printed by tools that produce and store key fingerprints
has changed. This includes the output of 'ssh-keygen', as well as the format
of the $HOME/.ssh/known_hosts file and others.
Old key fingerprints are the MD5 hash of the public key, encoded in
colon-separated hex. MD5 hashes are considered weak by modern standards and
are generally not recommended for cryptographic use.
Example of old format:
$ ssh-keygen -l -f ~/.ssh/id_rsa
2048 2c:be:e8:b1:32:02:31:aa:aa:aa:aa:aa:aa:aa:aa:aa alex.wilson@mbp (RSA)
New format:
$ ssh-keygen -l -f ~/.ssh/id_rsa
2048 SHA256:TY9lRcv8DzAXVo8CyRdvjuxqo6tsbFFAJ1aaaaaaaaa alex.wilson@mbp (RSA)
You can get the old format back by using the -E md5 option to most commands,
if needed. You will likely have to remove the MD5: prefix with 'sed'.
"known_hosts" files from the old SunSSH version are useable and compatible
with the new OpenSSH. This compatibility does not extend the other way,
however. The new OpenSSH will produce known_hosts entries in the new format,
which SunSSH will not understand.
Alternative key formats
=======================
SunSSH supports alternative key formats (RFC4716 and PKCS8) as well as the
standard SSH key format. OpenSSH will consider any keys not in the SSH key
format to be invalid.
If you've only ever used keys produced by ssh-keygen, it is unlikely you
have any keys that will be affected. This does not appear to have been a
widely-used feature.
Localization (l10n) and internationalization (i18n)
===================================================
SunSSH uses gettext and its own g11n module to localize strings such as
error messages and commandline options. These features are not available in
OpenSSH.
All error messages and text internally generated by SSH itself will be in
English and ASCII encoding. Conveniently, there are no actual translations
in the gate for any of this text, so unless you've been adding your own
locally this will be exactly the same behaviour you've had all along.
Additionally, the in-protocol language and locale negotiation that was
available when connecting from a SunSSH client to SunSSH daemon will no
longer be available. The language negotiation behaviour will be the same as
for OpenSSH on other systems.
X11 forwarding
==============
SunSSH's -X option has for a long time behaved as -Y does in other builds of
the SSH client (it operates in "trusted" mode). After this change, the SSH
client will revert to the upstream behaviour where -Y must be used to obtain
trusted forwarding.
Deprecated configuration options
================================
A few configuration options from SunSSH are now deprecated. The daemon will
accept them as valid options, but will ignore their values and they will not
have any effect.
* LookupClientHostnames and VerifyReverseMapping -- replaced by UseDNS
* MaxAuthTriesLog -- use MaxAuthTries
* RhostsAuthentication -- replaced by HostbasedAuthentication, but using
this is in general not recommended
* UseOpenSSLEngine -- no replacement, engines are used automatically
* GSSAPIStoreDelegatedCredentials -- no replacement, always true
* PreUserAuthHook -- no replacement
* KmfPolicyDatabase -- no replacement
* KmfPolicyName -- no replacement
* TrustedAnchorKeyStore -- no replacement
* UseUnsupportedSSHv1 -- no replacement
* UseFIPS140 -- no replacement
Additionally there are a few configuration options which were deprecated in
SunSSH, which will not be accepted by the new OpenSSH builds. If these
options are present in your configuration the new daemon will fail to start:
* GSSKeyEx -- use GSSAPIKeyExchange
* GSSAuthentication -- use GSSAPIAuthentication
* GSSDelegateCreds -- use GSSAPIDelegateCredentials
Privilege separation chroot
===========================
The new daemon will chroot to the directory /var/empty as part of the
privilege separation process. This directory will be created by the daemon
at startup if it does not exist on your system.
Deleting this directory after the daemon has started could result in a
situation where the SSH daemon is unable to accept new logins. Please don't
do that.
Old SunSSH workarounds
======================
The SunSSH daemon had code workarounds for bugs in very old SunSSH clients
(from the early Solaris 10 era and earlier). These workarounds will not be
available in the new daemon.
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
