+1 On Friday, September 4, 2015, Blake Irvin <[email protected]> wrote:
> 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] > <javascript:_e(%7B%7D,'cvml','[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. > > > > http://www.listbox.com > > *smartos-discuss* | Archives > <https://www.listbox.com/member/archive/184463/=now> > <https://www.listbox.com/member/archive/rss/184463/26900931-98fbc364> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > -- Sebastien Perrreault Partner Les Technologies Alesium Inc P: 514-298-7193 F: 514-221-3668 E: [email protected] "Life's missed opportunities, at the end, may seem more poignant to us than those we embraced--because in our imagination they have a perfection that reality can never rival." -- Roger Ebert ------------------------------------------- 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
