According to http://www.openssh.com/txt/release-7.0 the ssh-dss host and user keys are disabled by default. This update broke my system in all ways. Incoming ssh connections were refused: Aug 12 18:53:35 htpc.hauihau.home sshd[453]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth] Aug 12 18:53:38 htpc.hauihau.home sshd[1237]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.10.48.227 user=root (related to PermitRootLogin no) I had to create a new ECDSA public key pair (which is of course not supported bei gnome-keyring :|) to be able to login. Also the way out by ssh'ing to any server now leads to: debug1: Skipping ssh-dss key /home/steffen/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes I've now masked >net-misc/openssh-7.0 in order to be able to work again. emerge info: Portage 2.2.20.1 (python 3.4.3-final-0, default/linux/amd64/13.0, gcc-5.2.0, glibc-2.21-r1, 4.1.5-HAUIHAU x86_64) ================================================================= System uname: Linux-4.1.5-HAUIHAU-x86_64-Intel-R-_Core-TM-_i3-4330_CPU_@_3.50GHz-with-gentoo-2.2 KiB Mem: 7808876 total, 6519732 free KiB Swap: 8388604 total, 8388604 free Timestamp of repository gentoo: Wed, 12 Aug 2015 09:30:01 +0000 sh bash 4.3_p39 ld GNU gold (Gentoo 2.25.1 p1.0 2.25.1) 1.11 app-shells/bash: 4.3_p39::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.22.0::gentoo dev-lang/python: 2.7.10::gentoo, 3.4.3::gentoo dev-util/cmake: 3.3.0::gentoo dev-util/pkgconfig: 0.28-r3::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r1::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1::gentoo sys-devel/gcc: 5.2.0::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r1::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 hauihau location: /usr/local/portage/hauihau masters: gentoo priority: 0 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--autounmask=n --keep-going=y --quiet-build=y --quiet-fail=y --with-bdeps=y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs compressdebug config-protect-if-modified distlocks ebuild-locks fakeroot fixlafiles merge-sync metadata-transfer news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-znow -Wl,--sort-common -Wl,--hash-style=gnu -Wl,--enable-new-dtags" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/home/gentoo/tmp/" USE="X a52 aac aalib acl alsa amd64 avx avx2 bash-completion berkdb bluray branding bzip2 cairo caps cdda cddb cdparanoia cdr cli cracklib crypt curl cxx dbus dga dri dts dv dvd encode exif ffmpeg flac fontconfig fortran ftp gd gdbm gif gmp gstreamer iconv icu imagemagick imlib ipv6 jpeg jpeg2k lame libcaca libnotify libsamplerate lzma lzo mad matroska mmx mmxext mng modules mp3 mpeg mtp multilib musepack ncurses nls nptl nsplugin ogg openal opengl openmp pam pcre pdf png policykit quicktime readline session sndfile spell sse sse2 sse3 sse4 sse4_1 sse4_2 ssl ssse3 svg syslog systemd tcpd theora threads tiff truetype udev unicode usb v4l vaapi vcd vim-syntax vorbis wavpack x264 xattr xcb xcomposite xinerama xml xmp xorg xosd xpm xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" LIRC_DEVICES="devinput" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python3_4" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby21" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="3.4" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Reproducible: Always
(In reply to Steffen Hau from comment #0) > According to http://www.openssh.com/txt/release-7.0 the ssh-dss host and > user keys are disabled by default. > Though those same notes say to reference http://www.openssh.com/legacy.html if you still need them. This should possibly be a news item or blog post. Otherwise, it's not really Gentoo's problem IMO.
commit 4594beb488ced4db4baa89b1adc09f1f18e9e461 Author: Michał Górny <mgorny@gentoo.org> Date: Wed Aug 12 20:36:56 2015 +0200 profiles: Mask net-misc/openssh-7.0_p1 due to #557388 Mask new OpenSSL versions because they refuse RSA and DSA keys by default which causes the upgrade to disable SSH connectivity on affected hosts without warning. Bug: https://bugs.gentoo.org/show_bug.cgi?id=557388 QA-masked now. This definitely needs a news item.
(In reply to Brian Evans from comment #1) > (In reply to Steffen Hau from comment #0) > > According to http://www.openssh.com/txt/release-7.0 the ssh-dss host and > > user keys are disabled by default. > > > > Though those same notes say to reference http://www.openssh.com/legacy.html > if you still need them. > > This should possibly be a news item or blog post. Otherwise, it's not > really Gentoo's problem IMO. If seen the site, but I had absolutely no luck with the -oHostKeyAlgorithms=+ssh-dss switch, it still said that ssh-dss key is not in PubkeyAcceptedKeyTypes. (In reply to Michał Górny from comment #2) > commit 4594beb488ced4db4baa89b1adc09f1f18e9e461 > Author: Michał Górny <mgorny@gentoo.org> > Date: Wed Aug 12 20:36:56 2015 +0200 > > profiles: Mask net-misc/openssh-7.0_p1 due to #557388 > > Mask new OpenSSL versions because they refuse RSA and DSA keys by > default which causes the upgrade to disable SSH connectivity on affected > hosts without warning. > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=557388 > > > QA-masked now. This definitely needs a news item. Thaks a lot for your quick response!
If you set "PubkeyAcceptedKeyTypes=+ssh-dss" in your sshd_config and reload sshd, dsa keys will work.
(In reply to Michał Górny from comment #2) > commit 4594beb488ced4db4baa89b1adc09f1f18e9e461 > Author: Michał Górny <mgorny@gentoo.org> > Date: Wed Aug 12 20:36:56 2015 +0200 > > profiles: Mask net-misc/openssh-7.0_p1 due to #557388 > > Mask new OpenSSL versions because they refuse RSA and DSA keys by > default which causes the upgrade to disable SSH connectivity on affected > hosts without warning. > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=557388 > > > QA-masked now. This definitely needs a news item. This is ridiculous. DSA keys should not be used on moderny systems anyway. Now you've fordced people to stick with vulnerable ssh versions and you're blocking an open security issue. Well done sir!
(In reply to Lars Wendler (Polynomial-C) from comment #5) It would be quite easy for you to write a proper news item to inform users and greatly reduce confusion here. vapier said this needs to "bake" before stabilizing anyway.
Please run login tests after sshd upgrade in any way. This will save you money & time on the long run.
Well, it's not my fault that upstream can't do sane release policy, like not forcing major functionality changes along with security fixes. I guess reverting the change via patch or default sshd_config change would be best if you want to quick-stabilize it.
(In reply to Michał Górny from comment #8) > Well, it's not my fault that upstream can't do sane release policy, like not > forcing major functionality changes along with security fixes. I guess > reverting the change via patch or default sshd_config change would be best > if you want to quick-stabilize it. Dropping support for insecure key types and algorithms _is_ a security fix as well. There is no point in having encryption if someone with a couple of hundred dollars for EC2 time can crack it in a few hours. I don't think we should be reverting this change with a patch to code or config, at most we should add a news item.
If I would have gotten a note that DSA and RSA are no longer supported per default in 7.0, I would have created new keys before I've logged out of my box.. sshd offers stronger algorithms for a long time and my client mostly uses ECDSA (if it's offered). I use DSA jst for publickey authentication as this is/was the least common denominator for my heterogeneous system landscape and I can unlock the private key in my with gnome keyring at login, which is not possible with ECDSA and ED25519. The fact to bump a version, which has such a dramatic change, should be worth a news item or some additional elog messages to inform the users about the change *before* they have no chance to log into their servers anymore...
no idea why people think rsa keys are disabled by default ... they're clearly not. only the old weak ssh-dss was disabled.
(In reply to Michał Górny from comment #8) > Well, it's not my fault that upstream can't do sane release policy, like not > forcing major functionality changes along with security fixes. I guess > reverting the change via patch or default sshd_config change would be best > if you want to quick-stabilize it. To be fair to upstream, the release notes for the previous version (6.9) stated that these would be disabled by default at runtime in 7.0.
to be clear, we're not reverting the defaults. there will be a news entry sent out and once that's been live for a little while, we'll unmask 7.0 again. people should be migrating away from weak keys and we'll be following upstream's guidance here. i already pushed an explicit warning in the ebuild itself: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=671b767a1b5a8119e43a63c167fadb27cfbb7929
(In reply to SpanKY from comment #13) > to be clear, we're not reverting the defaults. there will be a news entry > sent out and once that's been live for a little while, we'll unmask 7.0 > again. people should be migrating away from weak keys and we'll be > following upstream's guidance here. +1
(In reply to SpanKY from comment #11) > no idea why people think rsa keys are disabled by default ... they're > clearly not. only the old weak ssh-dss was disabled. Maybe because nobody bothered to inform them exactly what's happening, so they start guessing. I only read what was in the summary, and acted quickly. (In reply to Graham Murray from comment #12) > (In reply to Michał Górny from comment #8) > > Well, it's not my fault that upstream can't do sane release policy, like not > > forcing major functionality changes along with security fixes. I guess > > reverting the change via patch or default sshd_config change would be best > > if you want to quick-stabilize it. > > To be fair to upstream, the release notes for the previous version (6.9) > stated that these would be disabled by default at runtime in 7.0. Well, sure. However note that most sysadmins don't have time to read release notes for every software they're running. They expect distributions to collect important notes for them. Therefore, I'd say if this was known at 6.9: 1. Why nobody bothered to prepare the news item beforehand? It's not like people weren't able to update their keys before 7.0. 2. Why OpenSSH didn't warn when using deprecated key formats? Kinda the point of deprecating stuff is to warn before it is removed. As in 'BIG FAT WARNING, YOU NEED TO REPLACE YOUR KEYS', not 'sorry, please get someone down there to reinstate the access for you'.
(In reply to Michał Górny from comment #15) > (In reply to SpanKY from comment #11) > > no idea why people think rsa keys are disabled by default ... they're > > clearly not. only the old weak ssh-dss was disabled. > > Maybe because nobody bothered to inform them exactly what's happening, so > they start guessing. I only read what was in the summary, and acted quickly. Sorry, that was my mistake, I didn't read the release notes carefully. I've generated a new RSA key pair (which are supported by gnome-keyring) now and replaced my DSA public key on all servers with the new RSA public key.
This definately must bake; the instructions in legacy.html do not work and it looks like openssh 7.0 may actually be broken in this regard. NOTE: there's absolutely no security benefit to locking a user out of a *remote* system that only has a ssh-dss authorized_key. Think about it. I was locked out of polyp.arm.dev.gentoo.org yesterday and equery shows that it still has openssh-6.7_p1 installed. My old 1024 bit RSA key worked just fine with Openssh 7.0, but that didn't help with polyp because I couldn't log in to install it. It is incorrect to say that 'legacy.html' says how to fix things; apparently the '+ssh-dss' rune doesn't work, at least what it seems to do is set the whole list to '+ssh-dss' not append to it (according to ssh -G). I was also locked out of a non-Gentoo system yesterday and I'm not today after the down-grade; it's a SunOS 5.10 system and I tried every combination of hacking on the ssh -o options and .ssh/config (including explicitly adding ssh-dss to the lists) and *NOTHING* worked. The sshd on the SunOS system was built in January 2012... What I'm doing now is adding my 1024 bit RSA key to every remote machine I can *remember*, but not taking out the ssh-dss one just in case someone decides that 1024 bit RSA keys are not secure. This is not Gentoo specific but it is a classic case of too much security reducing security, and there have to be *FAR* better instructions in the news article than those in legacy.html because the Gentoo upgrade, when it happens, locks out access to non-Gentoo systems running old installations of ssh with, quite possibly, only DSA and RSA encryption support. It's trivial to test; just set up a dev account with *just* a ssh-dss in authorized_keys on an openssh 6.9 (or earlier) system then try to log in with a 7.0.
(In reply to John Bowler from comment #17) > This definately must bake; the instructions in legacy.html do not work and > it looks like openssh 7.0 may actually be broken in this regard. A Gentoo news item will be published with the correct instructions. It is currently being reviewed on the gentoo-dev mailing list. https://archives.gentoo.org/gentoo-dev/message/28636824b7c615f6fa9d4a63a1c2cb11
(In reply to Mike Gilbert from comment #18) > (In reply to John Bowler from comment #17) > > This definately must bake; the instructions in legacy.html do not work and > > it looks like openssh 7.0 may actually be broken in this regard. > > A Gentoo news item will be published with the correct instructions. It is > currently being reviewed on the gentoo-dev mailing list. > > https://archives.gentoo.org/gentoo-dev/message/ > 28636824b7c615f6fa9d4a63a1c2cb11 Ok, I'm going to unmask openssh-7 and try the variations on: + PubkeyAcceptedKeyTypes=+ssh-dss BUT, my problem is that I have remote machines with no password (I have to use ssh to log in) and I was unable to find a way to persuade 'ssh' (NOT 'sshd') to use the id_dsa. I don't need to make my machines less secure, I just need to be able to access other machines as a regular user to change my authorized_keys. I could see why it wasn't working yesterday, but I found no combination of options that I could set *as a user* to allow me to access the remote machines.
PubkeyAcceptedKeyTypes works as both a client and server setting. As a user, you can add it to ~/.ssh/config.
(In reply to Mike Gilbert from comment #20) > PubkeyAcceptedKeyTypes works as both a client and server setting. As a user, > you can add it to ~/.ssh/config. Well, yes, but that isn't in the emerge output of 7.0p1 and it isn't documented anywhere; I just spent about an hour discovering it; here's the long story: The suggested work round doesn't work for the user case; I upgraded to 7.0_p1, verified that I could no longer ssh to polyp.arm.dev.gentoo, added *THIS* line to /etc/ssh/sshd_config (as super-user, so a normal user can't do this): PubkeyAcceptedKeyTypes=+ssh-dss then tried ssh again; no change. After considerable messing around I deduced the work round; it is necessary to add it to /etc/ssh_config (or .ssh/config) or, for that matter, as a '-o' option on the command line. Weirdly, PubkeyAcceptedKeyTypes is not documented in ssh_config(5) (only in sshd_config(5)!) This line worked for me on 7.0: $ ssh '-oPubkeyAcceptedKeyTypes=+ssh-dss' polyp.arm.dev.gentoo.org But here's what happens on 6.9: $ ssh '-oPubkeyAcceptedKeyTypes=+ssh-dss' polyp.arm.dev.gentoo.org command-line: line 0: Bad configuration option: pubkeyacceptedkeytypes So I guess upstream realized that this was a problem but omitted to update the documentation or 'legacy.html'. The information also doesn't appear in the output of 'ssh -G', so I'm guessing 7.0 is a work in progress.
Suggested text: * Messages for package net-misc/openssh-7.0_p1: * Starting with openssh-7.0, support for ssh-dss keys was disabled due to their * weak sizes. If users on this system need to use ssh-dss keys to access * remote systems this can be done on a per-command basis using the * PubkeyAcceptedKeyTypes option: * * $ ssh '-oPubkeyAcceptedKeyTypes=+ssh-dss' user@machine.site * * This option can also be added to a user's .ssh/config file, for example: * * HOST machine.site * PubkeyAcceptedKeyTypes +ssh-dss * * Or to the system /etc/ssh_config configuration. It is recommended that this * is done until you are sure that all users have updated their ssh configurations * on *remote* machines (NOT this one) to use RSA or, if possible ed25519 keys. * * If users accessing *THIS* machine need to use DSA keys because their * local .ssh/authorized_keys files contain no alternatives to ssh-dss, you can * re-enable the key types by adding to your sshd_config: * * PubkeyAcceptedKeyTypes +ssh-dss * * You should however generate new keys using rsa or ed25519 and persuade or * force people who use this machine to swap to the new keys. (They typically * need access using their old key to do this!) Note that Gentoo will normally * have already generated new keys; check for /etc/ssh/ssh_host*_key It may be a foolish consistency but I omitted the '=' in the configuration file examples; the upstream files don't use it. I haven't verified that the sshd_config option does actually work; I just checked the user side.
sp: * need access using their old key to do this!) Note that Gentoo will normally - * have already generated new keys; check for /etc/ssh/ssh_host*_key + * have already generated new host keys; check for /etc/ssh/ssh_host*_key
Personally I think there should be an additional admonition to not restart the sshd service until it has been ensured that there are no DSA-only authorized_keys left on the system, or that the relevant option has been added to sshd_config.
news item pushed out. will give it a ~week and then unmask again.
unmasked: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67cd1956c3e54844b38fd96db32cef1da751ee91
