WARNING: no suitable primes in /etc/ssh/primes

Status changed to 'Confirmed' because the bug affects multiple users.

This cannot be a bug on architecture-s39064 and 14.04.3 release simultaniously, as there is no s39064 for 14.04.

@bugproxy -> why these tags were added? Is this an automation issue, or metadata issue on your side?

Assignee should be an appropriate screening team - probably taco or skipper.

looking at openssh source code:
#define _PATH_DH_MODULI SSHDIR "/moduli"
/* Backwards compatibility */
#define _PATH_DH_PRIMES SSHDIR "/primes"

both paths are defined, with primes being a legacy/compat one.
Ubuntu only uses the current default /moduli path.

These are documented in ssh-keygen, you can see this manpage over here too http://manpages.ubuntu.com/manpages/xenial/en/man1/ssh-keygen.1.html#contenttoc3

Note, openssh supports and can be forced to use more combinations on client <-> server than available in the moduli, hence the caveat as per manpage. If one needs moduli beyond what's available in /moduli path, one may need to generate extra ones.

Nonetheless, please provide information as to how to reproduce this error ssh client in use, ssh server in use, and version details of both client and server. Ideally including architecture and exact package version numbers. The combined metadata on this bug report is inconsistent, and I'm failing to reproduce the described errors.

------- Comment From <email address hidden> 2016-03-20 08:36 EDT-------
i hit this error while using JSCH from java to connect to Ubuntu.

dpkg --list openssh-server
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=====================================================-===============================-===============================-===============================================================================================================
ii openssh-server 1:7.1p2-2 s390x secure shell (SSH) server, for secure access from remote machines

hope this helps...
adding 1024 primes solved the problem but they should be shipped by default.

OFERBA, I suspect you have a different issue than this bug report, which is about a misleading pathname in an error message.

I'd suggest filing a new bug for your issue however I do not think it is appropriate to be shipping a new release with 1024 bit DH primes as a default supported configuration. See https://weakdh.org/ for more information.

Thanks

------- Comment From <email address hidden> 2016-03-22 10:45 EDT-------
just wanted to mention that this was fixed in Java 1.8 and the connection is working properly with the default installation of Ubuntu.
i haven't tested Java 1.7.

thank you.

Apologies for my late response. I am running different software now, but the 'bug' is still present. I can currently reproduce it as follows:

Server: openssh-server Version: 1:6.9p1-2ubuntu0.1, Architecture amd64 on Ubuntu 15.10 (wily)
Client: Prompt 2 v2.5.2 (Build 23057) on IOS 9.2.1 (see https://panic.com/prompt/)

My /etc/ssh/sshd_config mentions:
> KexAlgorithms <email address hidden>,diffie-hellman-group-exchange-sha256

When my /etc/ssh/moduli is generated to contain only 4096 bit primes, and I log in from my iPad using Prompt 2, the server logs the following message in /var/log/auth.log:

Mar 22 21:47:40 srv01 sshd[28876]: WARNING: no suitable primes in /etc/ssh/primes

The file /etc/ssh/primes does not exist on the server system; neither is it mentioned in the (FILES section of the) sshd(8) manpage, which, incidentally, does mention /etc/ssh/moduli. - The above message is not logged in case /etc/ssh/moduli is generated to contain all of 2048, 3072 and 4096 bit primes.

I hope the report is now as complete as it should be. In case I find other ways to reproduce the error, I will let you know.

Perhaps the following is helpful in tracing the problem. It is an excerpt from /var/log/auth.log covering the ssh login from the iPad on the server (srv01) in the situation described earlier, logged at LogLevel DEBUG3:

Mar 23 08:33:14 srv01 sshd[1782]: Connection from ***.***.***.66 port 59484 on ***.***.***.34 port ***22
Mar 23 08:33:14 srv01 sshd[1782]: debug1: Client protocol version 2.0; client software version OpenSSH_5.4
Mar 23 08:33:14 srv01 sshd[1782]: debug1: match: OpenSSH_5.4 pat OpenSSH_5* compat 0x0c000000
Mar 23 08:33:14 srv01 sshd[1782]: debug1: Enabling compatibility mode for protocol 2.0
Mar 23 08:33:14 srv01 sshd[1782]: debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
Mar 23 08:33:14 srv01 sshd[1782]: debug2: fd 3 setting O_NONBLOCK
Mar 23 08:33:14 srv01 sshd[1782]: debug2: Network child is on pid 1783
Mar 23 08:33:14 srv01 sshd[1782]: debug3: preauth child monitor started
Mar 23 08:33:14 srv01 sshd[1782]: debug3: privsep user:group 104:65534 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug1: permanently_set_uid: 104/65534 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug1: list_hostkey_types: ssh-ed25519,ssh-rsa [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug1: SSH2_MSG_KEXINIT received [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: <email address hidden>,diffie-hellman-group-exchange-sha256 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: ssh-ed25519,ssh-rsa [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: <email address hidden>,<email address hidden>,aes256-ctr,aes192-ctr [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: <email address hidden>,<email address hidden>,aes256-ctr,aes192-ctr [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: none,<email address hidden> [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: none,<email address hidden> [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: reserved 0 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
Mar 23 08:33:14 srv01 sshd[1782]: debug2: kex_parse_kexinit: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rs...

Surely the bug is in Client: Prompt 2 v2.5.2 (Build 23057) on IOS 9.2.1 (see https://panic.com/prompt/), and you should report to them that it should use stronger keys to authenticate, no? We do not provide support for third party ssh clients. And we will not weaken our server to support weak clients.

Also wily 15.10 on amd64, is out of scope for s390x support on xenial.

Please let me know, if you can reproduce this at all with Ubuntu clients and Ubuntu server on s390x.

Sigh. No. It's a perfectly obvious bug in the OpenSSH client, it's just mostly cosmetic (i.e. it's checking two files but then only warning about one). Please read the original bug description carefully before closing this or arguing further about whether it's valid.

Sorry, I mean OpenSSH in general of course, not just the client.

And yes, the other end ought to be able to cope with stronger primes. But that's not what this bug is about: it specifically says "The alleged problem is the reference to /etc/ssh/primes instead of /etc/ssh/moduli".

Patch attached upstream https://bugzilla.mindrot.org/show_bug.cgi?id=2559 see https://bugzilla.mindrot.org/attachment.cgi?id=2801

As far as I understand there is no further actions for s390x port.

@OP this is a minor problem, and best addressed upstream, see upstream bug report linked.

This has been fixed in upstream openssh, and will be part of like 7.3 release or some such. When that gets released, makes it to debian and makes it to ubuntu, this bug will be resolved. This is a minor issue and not worth cherrypicking for. I'll just mark ubuntu task as fix released, cause we will forget to do so with 7.3 upload.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/dh.c?rev=1.59&content-type=text/x-cvsweb-markup

Thanks for your attention!

I won't forget to do it with the 7.3 upload, and would rather have the bug open until it's actually fixed.

This bug was fixed in the package openssh - 1:7.3p1-1

---------------
openssh (1:7.3p1-1) unstable; urgency=medium

  * New upstream release (http://www.openssh.com/txt/release-7.3):
    - SECURITY: sshd(8): Mitigate a potential denial-of-service attack
      against the system's crypt(3) function via sshd(8). An attacker could
      send very long passwords that would cause excessive CPU use in
      crypt(3). sshd(8) now refuses to accept password authentication
      requests of length greater than 1024 characters.
    - SECURITY: ssh(1), sshd(8): Fix observable timing weakness in the CBC
      padding oracle countermeasures. Note that CBC ciphers are disabled by
      default and only included for legacy compatibility.
    - SECURITY: ssh(1), sshd(8): Improve operation ordering of MAC
      verification for Encrypt-then-MAC (EtM) mode transport MAC algorithms
      to verify the MAC before decrypting any ciphertext. This removes the
      possibility of timing differences leaking facts about the plaintext,
      though no such leakage has been observed.
    - ssh(1): Add a ProxyJump option and corresponding -J command-line flag
      to allow simplified indirection through a one or more SSH bastions or
      "jump hosts".
    - ssh(1): Add an IdentityAgent option to allow specifying specific agent
      sockets instead of accepting one from the environment.
    - ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be
      optionally overridden when using ssh -W.
    - ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per
      draft-sgtatham-secsh-iutf8-00 (closes: #337041, LP: #394570).
    - ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K,
      4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03.
    - ssh-keygen(1), ssh(1), sshd(8): Support SHA256 and SHA512 RSA
      signatures in certificates.
    - ssh(1): Add an Include directive for ssh_config(5) files (closes:
      #536031).
    - ssh(1): Permit UTF-8 characters in pre-authentication banners sent
      from the server.
    - ssh(1), sshd(8): Reduce the syslog level of some relatively common
      protocol events from LOG_CRIT.
    - sshd(8): Refuse AuthenticationMethods="" in configurations and accept
      AuthenticationMethods=any for the default behaviour of not requiring
      multiple authentication.
    - sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN ATTEMPT!"
      message when forward and reverse DNS don't match.
    - ssh(1): Deduplicate LocalForward and RemoteForward entries to fix
      failures when both ExitOnForwardFailure and hostname canonicalisation
      are enabled.
    - sshd(8): Remove fallback from moduli to obsolete "primes" file that
      was deprecated in 2001 (LP: #1528251).
    - sshd_config(5): Correct description of UseDNS: it affects ssh hostname
      processing for authorized_keys, not known_hosts.
    - sshd(8): Send ClientAliveInterval pings when a time-based RekeyLimit
      is set; previously keepalive packets were not being sent.
    - sshd(8): Whitelist more architectures to enable the seccomp-bpf
      sandbox.
    - scp(1): Respect the local user's LC_CTYPE locale (clos...