Excellent! I applaud this pragmatic approach to keeping SmartOS relevant and low-friction for those new to the OS. Blake
On Sep 03, 2015, at 11:15 PM, Alex Wilson <[email protected]> wrote: 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
