From sleemburg at it-functions.nl Sat May 2 00:24:51 2015 From: sleemburg at it-functions.nl (Stephan Leemburg) Date: Fri, 1 May 2015 16:24:51 +0200 Subject: sftp chroot requirements Message-ID: <20150501142451.GA30760@recursive.jvc.nl> Hello, Is there any security reason why the last component of a chroot path is required to be owned by root and not by the user that is chroot-ed into that path? I have tried to think of a reason, but cannot find any except for when several accounts are chrooted into the same directory. But if that is not the case, then, is there any security consideration? If not, then it seems to me that permitting the last component to be owned by the user that is chrooted into it (maybe by a configuration option) would be very comfortable. I am currently in the process of - graduately - changing a chrooted vsftpd environment into a chrooted sftp setup. For time being, both must run simultanious until every 'user' has been migrated. This is an operational environment, that is used for uploading teletekst data for the Dutch national broadcasting agency, so it must continue to function. The homedirectories into which vsftpd chroot the users are owned by the users. They write directly into their home directories. Changing that will break interfaces. So, if chroot-sftp would - optionally - allow the final component to be owned by the user that would work. I'm looking forward to hear about the rationale why all components should be owned by root, or if the last component indeed does not have to be. Kind regards, Stephan From djm at mindrot.org Sat May 2 07:42:59 2015 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 May 2015 07:42:59 +1000 (AEST) Subject: sftp chroot requirements In-Reply-To: <20150501142451.GA30760@recursive.jvc.nl> References: <20150501142451.GA30760@recursive.jvc.nl> Message-ID: On Fri, 1 May 2015, Stephan Leemburg wrote: > Hello, > > Is there any security reason why the last component of a chroot path > is required to be owned by root and not by the user that is chroot-ed > into that path? This has been discussed on this mailing list several times in the past. You should check the archives. From sleemburg at it-functions.nl Sat May 2 07:53:12 2015 From: sleemburg at it-functions.nl (Stephan Leemburg) Date: Fri, 01 May 2015 23:53:12 +0200 Subject: sftp chroot requirements In-Reply-To: References: <20150501142451.GA30760@recursive.jvc.nl> Message-ID: <5543F5C8.2080601@it-functions.nl> I did not find any clues when 'googling' and could not find any search options on the archives. So, your answer does really not help. If you can help me with some reference, then it is highly appreciated. I would like to understand the rationaly. Not why 'it is just like it is'. No, why. What is the reasoning behind it. I speak Dutch, English, some Japanese and C. So, I can write something to patch it up in C. But if I do not understand the rationale behind it, what is the value of the writing in any language? If I do not understand the context, that you think I should implicitly understand, what should I do? I can send in a patch if you like. Kind regards, Stephan On 01-05-15 23:42, Damien Miller wrote: > On Fri, 1 May 2015, Stephan Leemburg wrote: > >> Hello, >> >> Is there any security reason why the last component of a chroot path >> is required to be owned by root and not by the user that is chroot-ed >> into that path? > This has been discussed on this mailing list several times in the past. > You should check the archives. From peter at stuge.se Sat May 2 08:23:20 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 2 May 2015 00:23:20 +0200 Subject: sftp chroot requirements In-Reply-To: <5543F5C8.2080601@it-functions.nl> References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> Message-ID: <20150501222320.3670.qmail@stuge.se> Stephan Leemburg wrote: > I did not find any clues when 'googling' and could not find any search > options on the archives. Try harder: http://marc.info/?l=openssh-unix-dev //Peter From sleemburg at hachimitsu.nl Sat May 2 09:07:55 2015 From: sleemburg at hachimitsu.nl (Stephan Leemburg) Date: Sat, 02 May 2015 01:07:55 +0200 Subject: sftp chroot requirements In-Reply-To: <20150501222320.3670.qmail@stuge.se> References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> <20150501222320.3670.qmail@stuge.se> Message-ID: <5544074B.3000403@hachimitsu.nl> Thank you. I looked through some. If I search on chroot, then I get a lot of things. But no rationale. So, where is the rationale? Where is the rationale behind the fact that the final component of the chroot path should be owned by root? As I already said - and now I also assume you know about all and everything I ever said - I do not see any security risk in the final chroot component being owned by the user if it is not a shared chroot end-path. I cannot find a rationale in the code. I cannot find it on 'the web'. Referring to some mailing lists is not helping. It does not state the rationale. Please explain the rationale behind the safe_chroot path checking. And document it. Why does the final component of the chroot path has to be owned by root? What security issues - that I cannot think of - would arise if it is not owned by root? Can I send in a patch? Just referring people to 'you did not look, go look $maybehere' does not really help. Not receiving an answer would be better than your answer. You seem to have background knowledge. You seem to recall discussions about chroot. Where these discussions also about the _why_ the ownership of the final component of the chroot is supposed to be root? Kind regards, Stephan On 02-05-15 00:23, Peter Stuge wrote: > Stephan Leemburg wrote: >> I did not find any clues when 'googling' and could not find any search >> options on the archives. > Try harder: http://marc.info/?l=openssh-unix-dev > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dkg at fifthhorseman.net Sat May 2 10:05:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 May 2015 20:05:35 -0400 Subject: sftp chroot requirements In-Reply-To: <20150501222320.3670.qmail@stuge.se> References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> <20150501222320.3670.qmail@stuge.se> Message-ID: <87r3qz973k.fsf@alice.fifthhorseman.net> On Fri 2015-05-01 18:23:20 -0400, Peter Stuge wrote: > Stephan Leemburg wrote: >> I did not find any clues when 'googling' and could not find any search >> options on the archives. > > Try harder: http://marc.info/?l=openssh-unix-dev This feels kind of rude. The OP has alreaday stated that he failed at searching, and folks on this list seem to know the answer and not give it to him. This is obviously a FAQ, so we should have a clear and concise writeup about why it is the way it is, maybe with pointers to other details if people want more depth. Here's a point from Jefferson Ogata: http://marc.info/?l=openssh-unix-dev&m=118591826828496&w=2 Here's another variant (slightly different) by Roman Fiedler: http://marc.info/?l=openssh-unix-dev&m=132983579918832&w=2 And another answer by ?ngel_Gonz?lez: http://marc.info/?l=openssh-unix-dev&m=135984176826142&w=2 that last thread has further discussion from Damien Miller as well. The basic concern is that (someone correct me if i'm off-base here) when / is writable, pretty much any deliberate privilege-escalation mechanism (setuid binaries is the obvious example -- are there others?) is likely to be exploitable by whoever can write to /. This is because most tools designed to do limited privilege escalation limit how their increased capabilities can be invoked by some sort of check in the filesystem, whether that's a dynamically-linked binary starting up with a compromised ld-linux.so.2; a modified /etc/shadow, /etc/group, or /etc/fstab, or some other mechanism. Perhaps a brief writeup (feel free to start from the above paragraph if it's not horribly wrong) could be added to the FAQ so that we have someplace concrete to point people the next time this comes up? http://www.openssh.com/faq.html this seems at least as frequently-asked as question 2.4 - "Why does OpenSSH print: Dispatch protocol error: type 20" ;) Happy hacking, --dkg From djm at mindrot.org Sat May 2 15:14:28 2015 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 May 2015 15:14:28 +1000 (AEST) Subject: sftp chroot requirements In-Reply-To: <5543F5C8.2080601@it-functions.nl> References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> Message-ID: On Fri, 1 May 2015, Stephan Leemburg wrote: > I did not find any clues when 'googling' and could not find any search options > on the archives. http://marc.info/?t=122641302700006&r=1&w=2 From sleemburg at hachimitsu.nl Sat May 2 23:05:44 2015 From: sleemburg at hachimitsu.nl (Stephan Leemburg) Date: Sat, 02 May 2015 15:05:44 +0200 Subject: sftp chroot requirements In-Reply-To: References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> Message-ID: <5544CBA8.1090207@hachimitsu.nl> Hi Damien, Thank you. I read the rationale. Just to summarize, a user writeable chroot target is considered dangerous if: 1) the user has another way of gaining non-chrooted access to the system 2) is able to create hardlinks to setuid-binaries outside of the chroot tree 3) there are bugs somewhere that allow privilige escalation or remote execution of other programs While all these arguments are legitimate, as can be - indeed - seen in CVE-2009-2904, I believe that there are also other situations. In our setup, we have users that currently only have vsftpd chrooted access. Their login shell is /sbin/nologin and they do not have any other way of accessing the system. So for this particular setup 1 and 2 are not applicable. I think 3 is not related to sftp chroot only, but in general. So, in my opinion there are use cases that would not compromise security by having the last component of the chroot sftp directory be owned by the user. If this could be a configurable option, then administrators that want to use such a setup could do so by explicitly allowing it. Is that something you could live with? If so, can I create a patch and send it in? Again, thank you for the pointers. I had trouble finding them with just plain search engine lookups. Kind regards, Stephan On 02-05-15 07:14, Damien Miller wrote: > > On Fri, 1 May 2015, Stephan Leemburg wrote: > >> I did not find any clues when 'googling' and could not find any search options >> on the archives. > http://marc.info/?t=122641302700006&r=1&w=2 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From nkadel at gmail.com Sun May 3 01:30:12 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 2 May 2015 11:30:12 -0400 Subject: sftp chroot requirements In-Reply-To: <5544CBA8.1090207@hachimitsu.nl> References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> <5544CBA8.1090207@hachimitsu.nl> Message-ID: On Sat, May 2, 2015 at 9:05 AM, Stephan Leemburg wrote: > Hi Damien, > > Thank you. I read the rationale. > > Just to summarize, a user writeable chroot target is considered dangerous > if: > > 1) the user has another way of gaining non-chrooted access to the system > 2) is able to create hardlinks to setuid-binaries outside of the chroot tree Improperly secured symlinks are a similar though not identical problem. The operating system does not know how to prevent a symlink inside a chroot cage from being allowed to write a system-read file for which that nominal chrooted user has privileges. Hilarity can ensue. > 3) there are bugs somewhere that allow privilige escalation or remote > execution of other programs I've been reviewing some of this lately, related to sftp, scp, and rsync chrooted targets managed thorugh the 'rssh' software. There are fascinating escalations that can happen. For example, 'suid' and 'sgid' are related but independent properties > While all these arguments are legitimate, as can be - indeed - seen in > CVE-2009-2904, I believe that there are also other situations. > > In our setup, we have users that currently only have vsftpd chrooted access. > Their login shell is /sbin/nologin and they do not have any other way of > accessing the system. So for this particular setup 1 and 2 are not > applicable. vsftpd doesn't keep the vsftpd binary, itself, inside the chroot cage or any loadable libraries that might be found there. That is part of where the problem comes from: you have to bring in quite a lot of components tools to allow sftp or scp or ssh over rsync to operate inside such a cage. And if you bring in copies of files, rather than hardlinks or symlinks, how do you make sure they stay updated when you update system OpenSSH or system libraries? That is partly why I spent time recently on updating a 'mkchroot.sh' script precisely for rssh users, at https://github.com/nkadel/rssh-chroot-tools. > I think 3 is not related to sftp chroot only, but in general. > So, in my opinion there are use cases that would not compromise security by > having the last component of the chroot sftp directory be owned by the user. > If this could be a configurable option, then administrators that want to use > such a setup could do so by explicitly allowing it. If they can do an rsync, or write directly to it, they can re-arange and replace bin or lib. That's pretty close to the core of the concern. I freely admit that in almost cases where people really need a chroot cage, OpenSSH cages are the wrong solution. vsftpd works pretty well. Git works well, and gets revision history, for recording changes. Even WebDAV over HTTPS can work pretty well, and none of those have to have anything owned by root or run as a root user inside the chroot cage. If you *must* use chroot cages, you might look at using rssh as a wrapper for it. It's a lot easier, and more stable than trying to maintain the patched OpenSSH often used for full chroot cage operations. > Is that something you could live with? If so, can I create a patch and send > it in? > > Again, thank you for the pointers. I had trouble finding them with just > plain search engine lookups. > > Kind regards, > Stephan From peter at stuge.se Sun May 3 02:05:58 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 2 May 2015 18:05:58 +0200 Subject: sftp chroot requirements In-Reply-To: References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> <5544CBA8.1090207@hachimitsu.nl> Message-ID: <20150502160558.13919.qmail@stuge.se> Nico Kadel-Garcia wrote: > bring in quite a lot of components tools to allow sftp or scp or ssh > over rsync Yeah no better use internal-sftp, but that is of course only sftp and nothing else. //Peter From nkadel at gmail.com Sun May 3 03:01:58 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 2 May 2015 13:01:58 -0400 Subject: sftp chroot requirements In-Reply-To: <20150502160558.13919.qmail@stuge.se> References: <20150501142451.GA30760@recursive.jvc.nl> <5543F5C8.2080601@it-functions.nl> <5544CBA8.1090207@hachimitsu.nl> <20150502160558.13919.qmail@stuge.se> Message-ID: On Sat, May 2, 2015 at 12:05 PM, Peter Stuge wrote: > Nico Kadel-Garcia wrote: >> bring in quite a lot of components tools to allow sftp or scp or ssh >> over rsync > > Yeah no better use internal-sftp, but that is of course only sftp and > nothing else. > > > //Peter And sftp doesn't support built-in content mirroring, unlike rsync over SSH. From fedor.brunner at azet.sk Mon May 4 23:30:45 2015 From: fedor.brunner at azet.sk (Fedor Brunner) Date: Mon, 04 May 2015 15:30:45 +0200 Subject: Obsolete MD5 Message-ID: <55477485.2000800@azet.sk> Hi, are there any plans to obsolete the MD5 in OpenSSH ? Would it be possible to remove hmac-md5-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-md5-96 from the default list of MACs ? http://www.di.ens.fr/~fouque/pub/crypto07b.pdf According to RFC 4253, hmac-md5 and hmac-md5-96 are only optional. Fedor From dgy.jr92 at gmail.com Tue May 5 00:08:50 2015 From: dgy.jr92 at gmail.com (=?UTF-8?Q?Gy=C3=B6rgy_Demarcsek_Ifj=2E?=) Date: Mon, 4 May 2015 16:08:50 +0200 Subject: OpenSSH two-factor authentication combined with Kerberos / PubKeyAuth Message-ID: Dear OpenSSH Development Team, I'm writing because I have trouble implementing a relatively straightforward authentication scenario with OpenSSH Server and I could not find any useful information by googling and probably you are my best choice to turn to because you must be the most familiar with the internals of OpenSSH. I'm trying to implement two-factor authentication for OpenSSH. The environment is Centos 7 (kernel: 3.10.0-229.1.2.el7.x86_64) with OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013. We have Active Directory (LDAP) + Kerberos deployed. The specification is as follows: - A user with an existing, valid Kerberos ticket must be asked only for the second factor - A user without an existing, valid Kerberos ticket must be asked for both his password and a second factor - Local users (no LDAP acc.) should be able to authenticate with their local passwords - The second factor must not be offered before the first one - Besides Kerberos, public key authentication should be also accepted as first factor if available - The feature should be able to be limited to a set of users - others just get let in with their passwords For performing the second factor's authentication process, there is 3rd party a PAM module available that knows nothing about Kerberos. So here is what I did: Put these lines into /etc/ssh/sshd_config: # To enable PAM - this will make sshd use PAM with configuration /etc/pam.d/sshd UsePam yes ChallengeResponseAuthentication yes # To enable Kerberos and public key authentication - it will let sshd use existing Kerberos tickets GSSAPIAuthentication yes # Enable public key authentication PubkeyAuthentication yes # Password validation should be done via the KDC PasswordAuthentication yes KerberosAuthentication yes KerberosOrLocalPasswd yes # Kerberos / Public Key + PAM AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam publickey,keyboard-interactive:pam password,keyboard-interactive:pam # (only supported for OpenSSH 6.2 or higher) The auth section of the PAM configuration for sshd (/etc/pam.d/sshd) auth [success=ignore default=1] pam_localuser.so auth substack password-auth auth [success=1 default=ignore] pam_localuser.so auth required pam_2fa.so [...some arguments...] auth include postlogin The module pam_2fa.so is responsible for prompting for and validating the second factor. Now for Kerberos, this does almost everything I wanted to achieve. However, for local accounts, it results in two subsequent password prompts. This is my main problem here. This is because in this case the path "password,keyboard-interactive:pam" is used,as expected. (I need this auth. path so someone with a Kerberos account but without a valid ticket can get a ticket by entering the password then the OTP.) If I remove the password-auth substack completely from the PAM config, then Kerberos accounts remain working and local accounts remain not working. To me, it seems like the KerberosOrLocalPasswd yes statement gets ignored, because UsePAM yes is also present. However, sshd really keeps using KDC for password validation, because otherwise it would not work for LDAP accounts either. So again, to further clarify what I wish to implement here is the pseudocode that described the desired authentication logic: if gssapi_auth_ok(principal) or pubkey_auth_ok(pubkey): return second_factor_auth(user, read_otp()) else: if is_local_account(user): return local_passwd_auth(user, read_password()) else: if krb5_auth(principal, read_password()): return second_factor_auth(user, read_otp()) return AUTH_ERR So my scenario I think is not too complex or ambitious in any way, but I still could not find a clear way to implement it despite I spent days researching and experimenting. Could you please help me find a solution? Thank you very much in advance! Cheers, Gyorgy Demarcsek From list at eworm.de Tue May 5 05:21:23 2015 From: list at eworm.de (Christian Hesse) Date: Mon, 4 May 2015 21:21:23 +0200 Subject: fatal: ssh_dispatch_run_fatal: Connection reset by peer [preauth] Message-ID: <20150504212123.4d9f10d9@leda.localdomain> Hello everybody, I have systemd set up to listen on ssh socket (:::22), the connection is handled to sshd via socket activation. Usually this works perfectly fine. However the service is checked from nagios. Sometimes the host logs: systemd[1]: Started OpenSSH Per-Connection Daemon ([::1]:60865). systemd[1]: Starting OpenSSH Per-Connection Daemon ([::1]:60865)... systemd[1]: Started OpenSSH Per-Connection Daemon (127.0.0.1:41286). systemd[1]: Starting OpenSSH Per-Connection Daemon (127.0.0.1:41286)... sshd[2854]: Connection closed by ::1 [preauth] sshd[2855]: fatal: ssh_dispatch_run_fatal: Connection reset by peer [preauth] Looks like this happens if we have two incoming connection (::1 and 127.0.0.1 are checked) at the some time. Why does this happen? Who's fault is it? As these are TCP connections I would expect it is not a problem to know what packet belongs to what connection. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);} -------------- next part -------------- A non-text attachment was scrubbed... Name: lo.pcap Type: application/vnd.tcpdump.pcap Size: 3730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From keisial at gmail.com Tue May 5 06:18:10 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 04 May 2015 22:18:10 +0200 Subject: Test coverage results available online In-Reply-To: References: Message-ID: <5547D402.6050709@gmail.com> On 24/04/15 13:06, Harri Porten wrote: > Dear OpenSHH developers, > > in case this helps with your testing efforts: > > At > > http://www.opencoverage.net/projects/openssh/index_html/sources.html > > you'll find an overview of the condition/decision code coverage as > achieved through a run of the test suite. The state last used is from > the git master branch commit 70860b6. The pages for openssh and libressl coverage are missing (fail with 404). From djm at mindrot.org Tue May 5 12:18:46 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 5 May 2015 12:18:46 +1000 (AEST) Subject: Obsolete MD5 In-Reply-To: <55477485.2000800@azet.sk> References: <55477485.2000800@azet.sk> Message-ID: On Mon, 4 May 2015, Fedor Brunner wrote: > Hi, > are there any plans to obsolete the MD5 in OpenSSH ? > > Would it be possible to remove > hmac-md5-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-md5-96 from > the default list of MACs ? You can do that if you want. There's no pressing reason to, since HMAC-MD5 is still considered safe, cf. http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html -d From djm at mindrot.org Tue May 5 12:34:26 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 5 May 2015 12:34:26 +1000 (AEST) Subject: OpenSSH two-factor authentication combined with Kerberos / PubKeyAuth In-Reply-To: References: Message-ID: On Mon, 4 May 2015, Gy?rgy Demarcsek Ifj. wrote: > Dear OpenSSH Development Team, > > I'm writing because I have trouble implementing a relatively > straightforward authentication scenario with OpenSSH Server and I could not > find any useful information by googling and probably you are my best choice > to turn to because you must be the most familiar with the internals of > OpenSSH. > > I'm trying to implement two-factor authentication for OpenSSH. The > environment is Centos 7 (kernel: 3.10.0-229.1.2.el7.x86_64) with > OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013. We have Active Directory > (LDAP) + Kerberos deployed. The specification is as follows: It looks like your 2nd factor is going via PAM. This makes things difficult (see below). > - A user with an existing, valid Kerberos ticket must be asked only for > the second factor This is pretty easy using AuthenticationMethods > - A user without an existing, valid Kerberos ticket must be asked for both > his password and a second factor This might be tricky if you are using a challenge/response 2nd factor because both would go via PAM and there is no signalling between sshd and the PAM stack that could be used to tell the latter that it needs to ask for password+challenge/response rather than just password. > - Local users (no LDAP acc.) should be able to authenticate with their > local passwords The only way this could be expressed in sshd is by putting all local users into a group and then using "Match group" to vary their AuthenticationMethods. > - The second factor must not be offered before the first one AuthenticationMethods controls the ordering of the methods offered, so this should be possible. > - Besides Kerberos, public key authentication should be also accepted as > first factor if available Subject to the caveats about, this can be done with AuthenticationMethods too. > - The feature should be able to be limited to a set of users - others just > get let in with their passwords Again, you'll need to set this up using groups. > For performing the second factor's authentication process, there is 3rd > party a PAM module available that knows nothing about Kerberos. So here is > what I did: > > Put these lines into /etc/ssh/sshd_config: ... > KerberosAuthentication yes > KerberosOrLocalPasswd yes If PAM is handling the password authentication, them I'm not sure whether this will make much difference. > # Kerberos / Public Key + PAM > AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam > publickey,keyboard-interactive:pam password,keyboard-interactive:pam The problem here is the last stanza: password,keyboard-interactive:pam since PAM is handling password authentication under the hood too, but PAM password authentication is a bit of a hack and only works when the PAM configuration makes a single password prompt and expects a single reply. Your PAM stack wants a password and a 2FA response, so the 'password' authn method won't work. I don't know how to solve this with the current signalling between sshd and PAM sorry. > Now for Kerberos, this does almost everything I wanted to achieve. However, > for local accounts, it results in two subsequent password prompts. This is > my main problem here. This is because in this case the path > "password,keyboard-interactive:pam" > is used,as expected. (I need this auth. path so someone with a Kerberos > account but without a valid ticket can get a ticket by entering the > password then the OTP.) If I remove the password-auth substack completely > from the PAM config, then Kerberos accounts remain working and local > accounts remain not working. To me, it seems like the KerberosOrLocalPasswd > yes statement gets ignored, because UsePAM yes is also present. However, > sshd really keeps using KDC for password validation, because otherwise it > would not work for LDAP accounts either. It's probably using kerberos via PAM. > So my scenario I think is not too complex or ambitious in any way, but I > still could not find a clear way to implement it despite I spent days > researching and experimenting. Could you please help me find a solution? It might be possible to enhance sshd's signalling to PAM by stashing something in a _SSHD_COMPLETED_AUTH PAM environment variable (or somesuch) that modules could use to decide how to proceed, but I'm years rusty with PAM. Maybe Darren or someone else who's more familiar could suggest something. -d From djm at mindrot.org Tue May 5 12:36:32 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 5 May 2015 12:36:32 +1000 (AEST) Subject: fatal: ssh_dispatch_run_fatal: Connection reset by peer [preauth] In-Reply-To: <20150504212123.4d9f10d9@leda.localdomain> References: <20150504212123.4d9f10d9@leda.localdomain> Message-ID: On Mon, 4 May 2015, Christian Hesse wrote: > Hello everybody, > > I have systemd set up to listen on ssh socket (:::22), the connection is > handled to sshd via socket activation. Usually this works perfectly fine. > > However the service is checked from nagios. Sometimes the host logs: > > systemd[1]: Started OpenSSH Per-Connection Daemon ([::1]:60865). > systemd[1]: Starting OpenSSH Per-Connection Daemon ([::1]:60865)... > systemd[1]: Started OpenSSH Per-Connection Daemon (127.0.0.1:41286). > systemd[1]: Starting OpenSSH Per-Connection Daemon (127.0.0.1:41286)... > sshd[2854]: Connection closed by ::1 [preauth] > sshd[2855]: fatal: ssh_dispatch_run_fatal: Connection reset by peer [preauth] > > Looks like this happens if we have two incoming connection (::1 and > 127.0.0.1 are checked) at the some time. > Why does this happen? Who's fault is it? As these are TCP connections I would > expect it is not a problem to know what packet belongs to what connection. You might need to look at server debug output and/or tcpdumps to see what is going on here, but it looks like whatever is making the connections is gracefully closing one but unceremoniously dropping the other. BTW openssh HEAD has a more useful error message for connections closed by TCP reset. -d From list at eworm.de Tue May 5 17:30:23 2015 From: list at eworm.de (Christian Hesse) Date: Tue, 5 May 2015 09:30:23 +0200 Subject: fatal: ssh_dispatch_run_fatal: Connection reset by peer [preauth] In-Reply-To: References: <20150504212123.4d9f10d9@leda.localdomain> Message-ID: <20150505093023.20afbe17@leda.localdomain> Damien Miller on Tue, 2015/05/05 12:36: > On Mon, 4 May 2015, Christian Hesse wrote: > > > Hello everybody, > > > > I have systemd set up to listen on ssh socket (:::22), the connection is > > handled to sshd via socket activation. Usually this works perfectly fine. > > > > However the service is checked from nagios. Sometimes the host logs: > > > > systemd[1]: Started OpenSSH Per-Connection Daemon ([::1]:60865). > > systemd[1]: Starting OpenSSH Per-Connection Daemon ([::1]:60865)... > > systemd[1]: Started OpenSSH Per-Connection Daemon (127.0.0.1:41286). > > systemd[1]: Starting OpenSSH Per-Connection Daemon (127.0.0.1:41286)... > > sshd[2854]: Connection closed by ::1 [preauth] > > sshd[2855]: fatal: ssh_dispatch_run_fatal: Connection reset by peer > > [preauth] > > > > Looks like this happens if we have two incoming connection (::1 and > > 127.0.0.1 are checked) at the some time. > > Why does this happen? Who's fault is it? As these are TCP connections I > > would expect it is not a problem to know what packet belongs to what > > connection. > > You might need to look at server debug output and/or tcpdumps to see > what is going on here, but it looks like whatever is making the connections > is gracefully closing one but unceremoniously dropping the other. > > BTW openssh HEAD has a more useful error message for connections closed > by TCP reset. Tried with HEAD from git master, but I can not reproduce it there... I will let you know if I can give more information about what is going on. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From list at eworm.de Tue May 5 19:58:51 2015 From: list at eworm.de (Christian Hesse) Date: Tue, 5 May 2015 11:58:51 +0200 Subject: fatal: ssh_dispatch_run_fatal: Connection reset by peer [preauth] In-Reply-To: <20150505093023.20afbe17@leda.localdomain> References: <20150504212123.4d9f10d9@leda.localdomain> <20150505093023.20afbe17@leda.localdomain> Message-ID: <20150505115851.30c4a9cd@leda.localdomain> Christian Hesse on Tue, 2015/05/05 09:30: > Damien Miller on Tue, 2015/05/05 12:36: > > On Mon, 4 May 2015, Christian Hesse wrote: > > > > > Hello everybody, > > > > > > I have systemd set up to listen on ssh socket (:::22), the connection is > > > handled to sshd via socket activation. Usually this works perfectly > > > fine. > > > > > > However the service is checked from nagios. Sometimes the host logs: > > > > > > systemd[1]: Started OpenSSH Per-Connection Daemon ([::1]:60865). > > > systemd[1]: Starting OpenSSH Per-Connection Daemon ([::1]:60865)... > > > systemd[1]: Started OpenSSH Per-Connection Daemon (127.0.0.1:41286). > > > systemd[1]: Starting OpenSSH Per-Connection Daemon (127.0.0.1:41286)... > > > sshd[2854]: Connection closed by ::1 [preauth] > > > sshd[2855]: fatal: ssh_dispatch_run_fatal: Connection reset by peer > > > [preauth] > > > > > > Looks like this happens if we have two incoming connection (::1 and > > > 127.0.0.1 are checked) at the some time. > > > Why does this happen? Who's fault is it? As these are TCP connections I > > > would expect it is not a problem to know what packet belongs to what > > > connection. > > > > You might need to look at server debug output and/or tcpdumps to see > > what is going on here, but it looks like whatever is making the > > connections is gracefully closing one but unceremoniously dropping the > > other. > > > > BTW openssh HEAD has a more useful error message for connections closed > > by TCP reset. > > Tried with HEAD from git master, but I can not reproduce it there... > I will let you know if I can give more information about what is going on. Just bisected the issue... Looks like commit 671eb9676cc78de450e68efae5443a3be649da89 ("refactor ssh_dispatch_run_fatal() to use sshpkt_fatal()") fixes this. Thanks a lot! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From porten at froglogic.com Wed May 6 03:37:01 2015 From: porten at froglogic.com (Harri Porten) Date: Tue, 5 May 2015 19:37:01 +0200 (CEST) Subject: Test coverage results available online In-Reply-To: <5547D402.6050709@gmail.com> References: <5547D402.6050709@gmail.com> Message-ID: On Mon, 4 May 2015, ?ngel Gonz?lez wrote: > The pages for openssh and libressl coverage are missing (fail with 404). Thanks for the hint, ?ngel. There were problems with the build and test run for these projects in our infrastructure yesterday. Sorry. We'll switch to keeping old results around if current builds fail. http://www.opencoverage.net/openssh http://www.opencoverage.net/libressl If of interest, we can add a "diff" against the last public release btw. This would show whether added or changed code has any test coverage. Harri. From keisial at gmail.com Wed May 6 10:42:18 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 06 May 2015 02:42:18 +0200 Subject: Test coverage results available online In-Reply-To: References: <5547D402.6050709@gmail.com> Message-ID: <5549636A.3030607@gmail.com> On 05/05/15 19:37, Harri Porten wrote: > Thanks for the hint, ?ngel. There were problems with the build and > test run for these projects in our infrastructure yesterday. Sorry. > We'll switch to keeping old results around if current builds fail. Thank you for sharing those results, Harri. Hopefully, they will be of help for improving the software tests. From martino87rm at gmail.com Tue May 19 20:21:29 2015 From: martino87rm at gmail.com (Martino Io) Date: Tue, 19 May 2015 12:21:29 +0200 Subject: Login grace period implications Message-ID: Good morning, recently I run into some troubles with some pseudo "expect" application; after hours of debugging I've realized that I've been hitting the login grace period wall; first point here (was using v 6.0.0) is that there is no debug message saying that connection was dropped due to that reason, the debug log (DEBUG3) was unbelievably silent, wondering if I should write a small patch to inform in DEBUG1 that a timeout has been reached. Second point is that the solution for my problem has been to increase such period to 5 minutes, while the SSH daemon doesn't listen on any publicly exposed interface I would like to hear your opinion on having it set to 300 seconds; are there any security implications during the key exchange because of that? I know that a could be more vulnerable to a DoS exhausting my sessions, apart from that is there anything relevant from a security point? Thanks -- Marcin From skraw at ithnet.com Wed May 20 19:48:51 2015 From: skraw at ithnet.com (Stephan von Krawczynski) Date: Wed, 20 May 2015 11:48:51 +0200 Subject: Re-install libwrap in OpenSSH Message-ID: <20150520114851.eee150c3.skraw@ithnet.com> Hello all, after a useless discussion on the opensuse ML I had to find out that they buried the removal news of libwrap last year in some half-sentence. So this is unfortunately pretty late for the topic. Nevertheless it is pretty obvious that you did not get any feedback from people using ssh over decades in server-administration. Let me make a clear point: libwrap removal was a pretty bad idea. It is a well-used security feature that is _not_ replaceable by your match-statement. As a first libwrap has features that match does not have. Second libwrap is easy-to-use and offers a possibility to make securtiy adjustments in _one_ file for nearly all services, whereas you propose to edit proprietary config files of all services with proprietary config statements for each service. If you have 20 of those you end up editing 20 config files in 20 different places in the fs with at least 20 different statements. This is _shit_. I am not against your match statement, leave it as is. But do not drop libwrap. If you deny libwrap somebody will fork the project for sure. libwrap has not changed for years because it simply works. And firewall rules are no replacement for it, because libwrap is not only an ip filter. It seems you did not know that when you made the wrong decision. Please cc me in case as I am not reading the list. -- Regards, Stephan From peter at stuge.se Wed May 20 22:46:57 2015 From: peter at stuge.se (Peter Stuge) Date: Wed, 20 May 2015 14:46:57 +0200 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520114851.eee150c3.skraw@ithnet.com> References: <20150520114851.eee150c3.skraw@ithnet.com> Message-ID: <20150520124657.1571.qmail@stuge.se> Stephan von Krawczynski wrote: > it is pretty obvious I guess you're not only not subscribed to the development list, but you seem to also not have looked at the list archives. You can only seem like a troll if you act as if you know best but in fact you are wrong. It's up to you whether you want to risk that of course, but it's dangerous for your case. > libwrap removal was a pretty bad idea. There was discussion. I recommend that you look for it in the archives, so that you can join the discussion without repeating what has already been said. > _not_ replaceable by your match-statement. This rhetoric makes it sound like it is very important for you to distance yourself from the OpenSSH developers. That may not be such a great strategy when you want someone to do something for you. The rationale is that firewall rules can replace libwrap and that removing libwrap removes a significant attack surface exposed to the network. > make securtiy adjustments in _one_ file for nearly all services > whereas you propose to edit proprietary config files of all > services with proprietary config statements for each service. If you actually care about security then don't you need to hand-craft those config files regardless of libwrap? And 20 services on one system? That seems a high number to me. > If you deny libwrap That is already the case. > somebody will fork the project for sure. Go for it. I think uptake will be limited. I think your best bet will be for you to contribute modifications to your prefered distribution. > you made the wrong decision. Please cc me in case as I am not > reading the list. If you had been reading the list you would already have known everything I wrote in this email. //Peter From skraw at ithnet.com Wed May 20 23:58:22 2015 From: skraw at ithnet.com (Stephan von Krawczynski) Date: Wed, 20 May 2015 15:58:22 +0200 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520124657.1571.qmail@stuge.se> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> Message-ID: <20150520155822.8a79124a.skraw@ithnet.com> On Wed, 20 May 2015 14:46:57 +0200 Peter Stuge wrote: > Stephan von Krawczynski wrote: > > it is pretty obvious > > I guess you're not only not subscribed to the development list, but > you seem to also not have looked at the list archives. > > You can only seem like a troll if you act as if you know best but > in fact you are wrong. It's up to you whether you want to risk that > of course, but it's dangerous for your case. Are you already preparing for having no arguments? > > _not_ replaceable by your match-statement. > > This rhetoric makes it sound like it is very important for you to > distance yourself from the OpenSSH developers. That may not be such > a great strategy when you want someone to do something for you. > > The rationale is that firewall rules can replace libwrap and that > removing libwrap removes a significant attack surface exposed to the > network. Show me this as an example of your firewall skills and replace this hosts.allow entry: sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW This is only an example code, of course. > > somebody will fork the project for sure. > > Go for it. I think uptake will be limited. I think your best bet will > be for you to contribute modifications to your prefered distribution. Negative. Wait and see. > > you made the wrong decision. Please cc me in case as I am not > > reading the list. > > If you had been reading the list you would already have known > everything I wrote in this email. > > > //Peter I saw the wrong outcome of it, and will reverse it. -- Regards, Stephan From kuenne at rentec.com Thu May 21 00:53:47 2015 From: kuenne at rentec.com (Karsten =?ISO-8859-1?Q?K=FCnne?=) Date: Wed, 20 May 2015 10:53:47 -0400 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520124657.1571.qmail@stuge.se> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> Message-ID: <43420372.XWM13bZhBu@licorice> On Wednesday 20 May 2015 14:46:57 Peter Stuge wrote: > Stephan von Krawczynski wrote: > > it is pretty obvious > > I guess you're not only not subscribed to the development list, but > you seem to also not have looked at the list archives. > > You can only seem like a troll if you act as if you know best but > in fact you are wrong. It's up to you whether you want to risk that > of course, but it's dangerous for your case. > > > libwrap removal was a pretty bad idea. > > There was discussion. I recommend that you look for it in the > archives, so that you can join the discussion without repeating > what has already been said. > > > _not_ replaceable by your match-statement. > > This rhetoric makes it sound like it is very important for you to > distance yourself from the OpenSSH developers. That may not be such > a great strategy when you want someone to do something for you. > > The rationale is that firewall rules can replace libwrap and that > removing libwrap removes a significant attack surface exposed to the > network. > > > make securtiy adjustments in _one_ file for nearly all services > > whereas you propose to edit proprietary config files of all > > services with proprietary config statements for each service. > > If you actually care about security then don't you need to hand-craft > those config files regardless of libwrap? > > And 20 services on one system? That seems a high number to me. > > > If you deny libwrap > > That is already the case. > > > somebody will fork the project for sure. > > Go for it. I think uptake will be limited. I think your best bet will > be for you to contribute modifications to your prefered distribution. > > > you made the wrong decision. Please cc me in case as I am not > > reading the list. > > If you had been reading the list you would already have known > everything I wrote in this email. > Please ignore this troll! He already polluted the opensuse mailing list with his ignorant postings. Karsten. -- Sweet sixteen is beautiful Bess, And her voice is changing -- from "No" to "Yes". From mstone at mathom.us Thu May 21 01:05:34 2015 From: mstone at mathom.us (Michael Stone) Date: Wed, 20 May 2015 11:05:34 -0400 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520155822.8a79124a.skraw@ithnet.com> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> Message-ID: <20150520150534.GA3086@mathom.us> On Wed, May 20, 2015 at 03:58:22PM +0200, Stephan von Krawczynski wrote: >Show me this as an example of your firewall skills and replace this >hosts.allow entry: > >sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | >/bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW > > >This is only an example code, of course. It's an example of something really horrible. It might have seemed like a good idea in the 90s, but in a modern system that sort of alerting should be integrated into log monitoring (and should be much more comprehensive than a couple of services linked against wrappers). I think you're confirming the decision to remove wrapper support rather than demonstrating that it was a mistake. Mike Stone From peter at stuge.se Thu May 21 01:18:35 2015 From: peter at stuge.se (Peter Stuge) Date: Wed, 20 May 2015 17:18:35 +0200 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520155822.8a79124a.skraw@ithnet.com> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> Message-ID: <20150520151835.13535.qmail@stuge.se> Stephan von Krawczynski wrote: > Are you already preparing for having no arguments? I pointed out that your style of communication makes you look bad so that next time when you want something you can try to avoid risking that, because looking bad is sufficient for lots of people to ignore you, regardless of technical merits. > > The rationale is that firewall rules can replace libwrap > > Show me this as an example of your firewall skills and replace this > hosts.allow entry: > > sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | > /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW Linux netfilter has a nice ULOG target which can be used with a program much smaller than libwrap to accomplish the essential functionality above. I used ULOG for the first time somewhere between 7 and 10 years ago so it has been around for a while. But that's of course off-topic for this list, so let's stop here. What's on-topic is that firewalls are indeed able to replace the functionality. //Peter From skraw at ithnet.com Thu May 21 02:17:43 2015 From: skraw at ithnet.com (Stephan von Krawczynski) Date: Wed, 20 May 2015 18:17:43 +0200 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520150534.GA3086@mathom.us> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> Message-ID: <20150520181743.74b8c5d2.skraw@ithnet.com> On Wed, 20 May 2015 11:05:34 -0400 Michael Stone wrote: > On Wed, May 20, 2015 at 03:58:22PM +0200, Stephan von Krawczynski wrote: > >Show me this as an example of your firewall skills and replace this > >hosts.allow entry: > > > >sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | > >/bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW > > > > > >This is only an example code, of course. > > It's an example of something really horrible. It might have seemed like > a good idea in the 90s, but in a modern system that sort of alerting > should be integrated into log monitoring (and should be much more > comprehensive than a couple of services linked against wrappers). > > I think you're confirming the decision to remove wrapper support rather > than demonstrating that it was a mistake. > > Mike Stone Why do you think you really have understood all occasions and surroundings on which something like this can be deployed. Can you imagine there is infrastructure besides routed internet? -- Regards, Stephan From djm at mindrot.org Thu May 21 08:51:59 2015 From: djm at mindrot.org (Damien Miller) Date: Thu, 21 May 2015 08:51:59 +1000 (AEST) Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520114851.eee150c3.skraw@ithnet.com> References: <20150520114851.eee150c3.skraw@ithnet.com> Message-ID: I saw the abusive email you sent to me the other day. It's basically the perfect way to get developers to ignore you, which is exactly what I'm going to do now. On Wed, 20 May 2015, Stephan von Krawczynski wrote: > Hello all, > > after a useless discussion on the opensuse ML I had to find out that they > buried the removal news of libwrap last year in some half-sentence. So this is > unfortunately pretty late for the topic. Nevertheless it is pretty obvious > that you did not get any feedback from people using ssh over decades in > server-administration. Let me make a clear point: libwrap removal was a pretty > bad idea. It is a well-used security feature that is _not_ replaceable by your > match-statement. As a first libwrap has features that match does not have. > Second libwrap is easy-to-use and offers a possibility to make securtiy > adjustments in _one_ file for nearly all services, whereas you propose to edit > proprietary config files of all services with proprietary config statements > for each service. If you have 20 of those you end up editing 20 config files > in 20 different places in the fs with at least 20 different statements. This > is _shit_. I am not against your match statement, leave it as is. But do not > drop libwrap. If you deny libwrap somebody will fork the project for sure. > libwrap has not changed for years because it simply works. And firewall rules > are no replacement for it, because libwrap is not only an ip filter. It seems > you did not know that when you made the wrong decision. Please cc me in case > as I am not reading the list. > > -- > Regards, > Stephan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Thu May 21 09:28:05 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 May 2015 09:28:05 +1000 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150520150534.GA3086@mathom.us> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> Message-ID: On Thu, May 21, 2015 at 1:05 AM, Michael Stone wrote: > On Wed, May 20, 2015 at 03:58:22PM +0200, Stephan von Krawczynski wrote: > >> Show me this as an example of your firewall skills and replace this >> hosts.allow entry: >> >> sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected >> me | >> /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW >> >> >> This is only an example code, of course. >> > > It's an example of something really horrible. It might have seemed like a > good idea in the 90s, but in a modern system that sort of alerting should > be integrated into log monitoring (and should be much more comprehensive > than a couple of services linked against wrappers). > Note that you can still do that by starting sshd under tcpd+inetd, something like: ssh stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sshd -i or the equivalent in your inetd-alike. For SSHv2 connections it should be about the same speed (it'll be slower for Protocol 1 connections because each connection will need to generate a new ephemeral host key, but that's probably a plus from a security standpoint). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Eric.Wedaa at marist.edu Thu May 21 10:24:05 2015 From: Eric.Wedaa at marist.edu (Eric Wedaa) Date: Wed, 20 May 2015 20:24:05 -0400 Subject: Help with debug mode needed In-Reply-To: References: , <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> Message-ID: All; ? I'm working on an ssh honeypot to analyze botnets, and I'm trying to find the chunk of code that specifies the following (like in Kippo) TIMESTAMP [HoneyPotTransport,2522,XX.XX.XX.XX] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa TIMESTAMP [HoneyPotTransport,2522,XX.XX.XX.XX] outgoing: aes128-ctr hmac-sha1 none TIMESTAMP [HoneyPotTransport,2522,XX.XX.XX.XX] incoming: aes128-ctr hmac-sha1 none I was able to find the section in sshd.c where I can log the client name and port, and the section in auth.c where the password is cleartext, but I have no idea what I'm really looking for for finding the protocols. I honestly have no idea where I should really be looking.? If somebody can point me in the right direction (or send a code fragment) I'd really appreciate it.? I'll post a link back to the mailing list of where everyone else can find the completed code if I get some help. (BTW: It's live already at http://longtail.it.marist.edu and I've already found and/or analyzed 9 botnets.? Having better information on who's attacking will make it easier I hope to bunch them all together). (And no, I'm not rising to the bait about tcpwrappers :-) It's decided and done.) >>>Ericw From skraw at ithnet.com Thu May 21 16:21:34 2015 From: skraw at ithnet.com (Stephan von Krawczynski) Date: Thu, 21 May 2015 08:21:34 +0200 Subject: Re-install libwrap in OpenSSH In-Reply-To: References: <20150520114851.eee150c3.skraw@ithnet.com> Message-ID: <20150521082134.d4d8a5eb.skraw@ithnet.com> On Thu, 21 May 2015 08:51:59 +1000 (AEST) Damien Miller wrote: > I saw the abusive email you sent to me the other day. It's basically > the perfect way to get developers to ignore you, which is exactly what > I'm going to do now. I have not really expected a positive answer from someone removing a perfectly well ten-liner from code just to make thousands of people having to completely change their configs and possibly add more then the ten lines to other configs. That is not software development, that is sabotage. Thanks for top-posting, shows your true commitment. > On Wed, 20 May 2015, Stephan von Krawczynski wrote: > > > Hello all, > > > > after a useless discussion on the opensuse ML I had to find out that they > > buried the removal news of libwrap last year in some half-sentence. So this is > > unfortunately pretty late for the topic. Nevertheless it is pretty obvious > > that you did not get any feedback from people using ssh over decades in > > server-administration. Let me make a clear point: libwrap removal was a pretty > > bad idea. It is a well-used security feature that is _not_ replaceable by your > > match-statement. As a first libwrap has features that match does not have. > > Second libwrap is easy-to-use and offers a possibility to make securtiy > > adjustments in _one_ file for nearly all services, whereas you propose to edit > > proprietary config files of all services with proprietary config statements > > for each service. If you have 20 of those you end up editing 20 config files > > in 20 different places in the fs with at least 20 different statements. This > > is _shit_. I am not against your match statement, leave it as is. But do not > > drop libwrap. If you deny libwrap somebody will fork the project for sure. > > libwrap has not changed for years because it simply works. And firewall rules > > are no replacement for it, because libwrap is not only an ip filter. It seems > > you did not know that when you made the wrong decision. Please cc me in case > > as I am not reading the list. > > > > -- > > Regards, > > Stephan > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Regards, Stephan From skraw at ithnet.com Thu May 21 16:53:46 2015 From: skraw at ithnet.com (Stephan von Krawczynski) Date: Thu, 21 May 2015 08:53:46 +0200 Subject: Re-install libwrap in OpenSSH In-Reply-To: References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> Message-ID: <20150521085346.8412357a.skraw@ithnet.com> On Thu, 21 May 2015 09:28:05 +1000 Darren Tucker wrote: > On Thu, May 21, 2015 at 1:05 AM, Michael Stone wrote: > > > On Wed, May 20, 2015 at 03:58:22PM +0200, Stephan von Krawczynski wrote: > > > >> Show me this as an example of your firewall skills and replace this > >> hosts.allow entry: > >> > >> sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected > >> me | > >> /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW > >> > >> > >> This is only an example code, of course. > >> > > > > It's an example of something really horrible. It might have seemed like a > > good idea in the 90s, but in a modern system that sort of alerting should > > be integrated into log monitoring (and should be much more comprehensive > > than a couple of services linked against wrappers). > > > > Note that you can still do that by starting sshd under tcpd+inetd, > something like: > > ssh stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sshd -i > > or the equivalent in your inetd-alike. For SSHv2 connections it should be > about the same speed (it'll be slower for Protocol 1 connections because > each connection will need to generate a new ephemeral host key, but that's > probably a plus from a security standpoint). Thanks for your suggestion, one of the very few constructive postings regarding the issue. But if you compare the work loaded on admins all around the world produced by removing such a small piece of code to its benefits, don't you think the whole story looks more like a weird political issue. The maintainers cannot be that braindead to think they can tilt libwrap alltogether, there is wide use of it, probably more than OpenSSH. So the users and admins end up in a system where the majority of code is quite happy with libwrap and openSSH refusing it - without true replacement. If you do a risk-analysis, you have to admit that simply by using two binaries (inet+sshd) instead of one with an immanent security feature (sshd+libwrap) things have gotten worse. Let alone all the useless suggestions involving firewall->systemd->fail2ban schemes which do not help at all against stolen passwords or keys. Risk does increase with complexity of security measures so firewall per se is no real comparable option. Reasonable firewall rules tend to look like spaghetti code implementing a bigger number of to-be-whitelisted ips. In the end, every replacement for libwrap is just a risky and bad patch for the real thing. So why throw away code that works since decades, is simple, has simple usage pattern? If you cut off one of your legs, you cannot expect to run as fast and easy as one who doesn't even if you own a wheel chair. > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. -- Regards, Stephan From alon.barlev at gmail.com Thu May 21 18:15:59 2015 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 21 May 2015 11:15:59 +0300 Subject: [PATCH] build: ssh-agent: condition util.h include Message-ID: <1432196159-5063-1-git-send-email-alon.barlev@gmail.com> Signed-off-by: Alon Bar-Lev --- ssh-agent.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ssh-agent.c b/ssh-agent.c index 9e2a37f..415a5ea 100644 --- a/ssh-agent.c +++ b/ssh-agent.c @@ -68,7 +68,9 @@ #include #include #include +#ifdef HAVE_UTIL_H #include +#endif #include "key.h" /* XXX for typedef */ #include "buffer.h" /* XXX for typedef */ -- 2.3.6 From djm at mindrot.org Thu May 21 18:18:31 2015 From: djm at mindrot.org (Damien Miller) Date: Thu, 21 May 2015 18:18:31 +1000 (AEST) Subject: [PATCH] build: ssh-agent: condition util.h include In-Reply-To: <1432196159-5063-1-git-send-email-alon.barlev@gmail.com> References: <1432196159-5063-1-git-send-email-alon.barlev@gmail.com> Message-ID: ha, I just pushed a the same diff On Thu, 21 May 2015, Alon Bar-Lev wrote: > Signed-off-by: Alon Bar-Lev > --- > ssh-agent.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/ssh-agent.c b/ssh-agent.c > index 9e2a37f..415a5ea 100644 > --- a/ssh-agent.c > +++ b/ssh-agent.c > @@ -68,7 +68,9 @@ > #include > #include > #include > +#ifdef HAVE_UTIL_H > #include > +#endif > > #include "key.h" /* XXX for typedef */ > #include "buffer.h" /* XXX for typedef */ > -- > 2.3.6 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From alon.barlev at gmail.com Thu May 21 18:19:46 2015 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 21 May 2015 11:19:46 +0300 Subject: [PATCH] build: ssh-agent: condition util.h include In-Reply-To: References: <1432196159-5063-1-git-send-email-alon.barlev@gmail.com> Message-ID: :) On 21 May 2015 at 11:18, Damien Miller wrote: > ha, I just pushed a the same diff > > On Thu, 21 May 2015, Alon Bar-Lev wrote: > > > Signed-off-by: Alon Bar-Lev > > --- > > ssh-agent.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/ssh-agent.c b/ssh-agent.c > > index 9e2a37f..415a5ea 100644 > > --- a/ssh-agent.c > > +++ b/ssh-agent.c > > @@ -68,7 +68,9 @@ > > #include > > #include > > #include > > +#ifdef HAVE_UTIL_H > > #include > > +#endif > > > > #include "key.h" /* XXX for typedef */ > > #include "buffer.h" /* XXX for typedef */ > > -- > > 2.3.6 > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From opensshdev at r.paypc.com Thu May 21 18:35:10 2015 From: opensshdev at r.paypc.com (Malcolm) Date: Thu, 21 May 2015 01:35:10 -0700 Subject: Re-install libwrap in OpenSSH In-Reply-To: <20150521085346.8412357a.skraw@ithnet.com> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> <20150521085346.8412357a.skraw@ithnet.com> Message-ID: <1432197310.555d98be513465.73294104@www.paypc.com> Quoting Stephan von Krawczynski : > Let alone all the useless suggestions involving > firewall->systemd->fail2ban schemes which do not help at all against stolen > passwords or keys. Risk does increase with complexity of security measures > so firewall per se is no real comparable option. Reasonable firewall rules > tend to look like spaghetti code implementing a bigger number of > to-be-whitelisted ips. Why would they end up that way? Most organisations place firewalls at their network border or edge, and implement service access policies in a consistent and transparent manner as far as the servicing hosts themselves are concerned. Log coalescing allows "bruteforce" attacks to be collected and if necessary acted upon also in a centralised and consistent manner. The "economy" of which you speak regarding libwrap functionality sounds like each host you run operates like an island unto itself, rather than as a coordinated team of servers managed by consistent policy. > In the end, every replacement for libwrap is just a risky and bad patch for > the real thing. So why throw away code that works since decades, is simple, > has simple usage pattern? The OpenSSH team has no doubt looked at the "risk profile" of linking to various bits of code, and libwrap is by no means the only one to see a potential axe here. Notice too that OpenSSL's track record has gotten to the point where the OpenSSH team has looked to allow system administrators to build sshd/ssh WITHOUT linking against any OpenSSL code at all. Given how much cruft and "legacy" support that's been exploited for years by hackers and three-lettered US agencies alike, I think that's a sensible posture, to be honest. I just realised that I spent a non-trivial amount of time DISABLING MACs/KEXs/Ciphers across my entire organisation to the point where simply building without any OpenSSL would have probably saved much more time to start with! At some point, I think I'll make a "split patch" where the clients (ssh/scp) can get built one way and the server components another. Sure, I can simply build it twice and manually merge them today, but I'm a software engineer, not a system administrator, and I'm *LAZY*. Your approach is both counterproductive, and unnecessary. If you actually looked through the archives, you'll find patches to re-incorporate support for libwrap without any difficulty whatsoever into OpenSSH. It sounds like you are wanting to have it both ways - you mention a loathing for "fail2ban" and similar strategies - which are entirely automated surgical firewalling rules put into place to reduce bruteforce attack pressure on hosts, versus the "labour cost differential" of hand-edited host.allow/deny files. Are you saying that you prefer to manually enter and retire "attacking hosts' IP#s" that have too many password failures against your servers? =Malcolm= From nkadel at gmail.com Thu May 21 22:01:14 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 21 May 2015 08:01:14 -0400 Subject: Re-install libwrap in OpenSSH In-Reply-To: <1432197310.555d98be513465.73294104@www.paypc.com> References: <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> <20150521085346.8412357a.skraw@ithnet.com> <1432197310.555d98be513465.73294104@www.paypc.com> Message-ID: Please note: I am not a huge fan of libwrap, but the logic below has some very real flaws. I'd like to ensure that it's not accepted as complete or convincing in and of itself. On Thu, May 21, 2015 at 4:35 AM, Malcolm wrote: > Quoting Stephan von Krawczynski : > >> Let alone all the useless suggestions involving >> firewall->systemd->fail2ban schemes which do not help at all against stolen >> passwords or keys. Risk does increase with complexity of security measures >> so firewall per se is no real comparable option. Reasonable firewall rules >> tend to look like spaghetti code implementing a bigger number of >> to-be-whitelisted ips. > > Why would they end up that way? Because most firewall admins make only one line changes, and are scared spitless of breaking active services in a live environment. The result is spaghetti code. > Most organisations place firewalls at their network border or edge, and > implement service access policies in a consistent and transparent manner as > far as the servicing hosts themselves are concerned. Log coalescing allows At the edge, yes. Consistent and transparent? Oh, dear Lord, no. Most network groups are quite secretive about their network configurations, presenting a "just tell us what you need and we will do it" rather than being willing to share backups. I've in fact offered to refine the backup tools to strip critical SSL keys and encrypted passwords so that the data could be shared with the operations group, and been confronted with complete stonewalling from the network admins in almost every place I've worked in the last 20 years. And since checklists and guidelines often present confusing interfaces, the backups remain the real way to review what is *actually* being filtered. > "bruteforce" attacks to be collected and if necessary acted upon also in a > centralised and consistent manner. It could, yes, if the owners of the individual hosts could or would allow those logs to be centralized, and if resources were allocated to manage and review that collection. But those logs often, themselves, contain security sensitive data, such as usernames and passwords from accidentally swapped word swapped login sessions. It gets much, much worse if the log aggregation includes command line history, which more and more companies are doing" "Centrify" software makes a big deal of their modified shells that provide such logs, and I sent them some patches for their modified SSH servers. > The "economy" of which you speak regarding libwrap functionality sounds like > each host you run operates like an island unto itself, rather than as a > coordinated team of servers managed by consistent policy. This is, in fact, normal. Also, mistakes in libwrap do not take out the firewall for the entire company, including the access to the firewall itself. They can be implemented on weekends and only take out a few services on one server, with a *much* smaller risk of repercussions. >> In the end, every replacement for libwrap is just a risky and bad patch for >> the real thing. So why throw away code that works since decades, is simple, >> has simple usage pattern? > > The OpenSSH team has no doubt looked at the "risk profile" of linking to > various bits of code, and libwrap is by no means the only one to see a > potential axe here. > > Notice too that OpenSSL's track record has gotten to the point where the > OpenSSH team has looked to allow system administrators to build sshd/ssh > WITHOUT linking against any OpenSSL code at all. Given how much cruft and > "legacy" support that's been exploited for years by hackers and three-lettered > US agencies alike, I think that's a sensible posture, to be honest. Heck, yes. Others in the OpenBSD community are even working on LibreSSL, which I applaud them for. > I just realised that I spent a non-trivial amount of time DISABLING > MACs/KEXs/Ciphers across my entire organisation to the point where simply > building without any OpenSSL would have probably saved much more time to start > with! At some point, I think I'll make a "split patch" where the clients > (ssh/scp) can get built one way and the server components another. If it can be done as a ./configure option, that seems like a pretty good idea. > Sure, I can simply build it twice and manually merge them today, but I'm a > software engineer, not a system administrator, and I'm *LAZY*. I'm not using hosts.allow these days: and having multiple compilation options requires more testing and more test cases. > Your approach is both counterproductive, and unnecessary. If you actually > looked through the archives, you'll find patches to re-incorporate support for > libwrap without any difficulty whatsoever into OpenSSH. Been there, done that., especially for chroot cages for rsync and ssh. scp and sftp has never been sufficient for reliable content mirroring, due to inconsistent local timezone handling in the protocols and the inability to handle symlinks and hardlinks completely. The result has been nasty: if I'm going to allow rsync uploads, I have to manually fork OpenSSH for the old chroot cage patches, which have been consistently refused by the core maintainers, and keep remerging and manually updating that fork with every OpenSSH update. This is much easier now with git managed code, I admit, but it's still a pain in the keister. These days I'm using rssh with OpenSSH instead, and even publish and have submitted a chroot cage builder for it at https://github.com/nkadel/rssh-chroot-tools. I'm not wildly enthused about rssh, but it beats the heck out of maintaining my own OpenSSH builds,a nd the 'mkchroot.sh' tool is useful for either. > It sounds like you are wanting to have it both ways - you mention a loathing > for "fail2ban" and similar strategies - which are entirely automated surgical > firewalling rules put into place to reduce bruteforce attack pressure on > hosts, versus the "labour cost differential" of hand-edited host.allow/deny > files. > > Are you saying that you prefer to manually enter and retire "attacking hosts' > IP#s" that have too many password failures against your servers? > > =Malcolm= fail2ban solves different problems, and is itself often a useful tool. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From matthew at debian.org Thu May 21 23:26:33 2015 From: matthew at debian.org (Matthew Vernon) Date: Thu, 21 May 2015 14:26:33 +0100 Subject: Weak DH primes and openssh Message-ID: <555DDD09.3090606@debian.org> Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... The moduli file you provide has this distribution of sizes: size count 1023 36 1535 50 2047 36 3071 31 4095 41 6143 27 8191 39 Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist kit, which would seem to argue against re-generating them on users' machines. Regards, Matthew From scott_n at xypro.com Fri May 22 01:03:38 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 21 May 2015 15:03:38 +0000 Subject: Weak DH primes and openssh In-Reply-To: <555DDD09.3090606@debian.org> References: <555DDD09.3090606@debian.org> Message-ID: Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting? -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Matthew Vernon Sent: Thursday, May 21, 2015 6:27 AM To: openssh-unix-dev at mindrot.org Subject: Weak DH primes and openssh Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... The moduli file you provide has this distribution of sizes: size count 1023 36 1535 50 2047 36 3071 31 4095 41 6143 27 8191 39 Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist kit, which would seem to argue against re-generating them on users' machines. Regards, Matthew _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From ryan_cox at byu.edu Fri May 22 08:07:33 2015 From: ryan_cox at byu.edu (Ryan Cox) Date: Thu, 21 May 2015 16:07:33 -0600 Subject: [PATCH] Optionally allow pam_setcred to override gid In-Reply-To: <552C02EA.3010406@byu.edu> References: <552C02EA.3010406@byu.edu> Message-ID: <555E5725.7060209@byu.edu> Any thoughts on this approach? (Bugzilla entry added since the last email: https://bugzilla.mindrot.org/show_bug.cgi?id=2380) Thanks, Ryan On 04/13/2015 11:54 AM, Ryan Cox wrote: > I would like to allow pam_setcred/pam_sm_setcred to override the gid > that is normally set for a user. Currently the openssh code calls > do_pam_setcred then it sets the gid to the user's gid as listed in > /etc/passwd, LDAP, or whatever regardless of what the pam module set > it to. I would instead like a pam module to be able to set the gid > with setgid() and not have it overwritten by openssh. > > I wrote a patch that does just that by comparing getgid() before and > after calling do_pam_setcred. If the gid changes it sets pw->gid to > the new gid, which is used in later functions. I don't know if this > is considered the proper way to achieve that behavior in a safe way > but it seemed logical to me. The behavior is optional; > PermitGidOverride=no is the default. > > As for the reasoning, this is for a scheduled environment using > Slurm. I am developing a pam module that "adopts" ssh processes into > the appropriate batch job on the node. Users can launch jobs via > Slurm that run with their gid as one of their supplementary groups. > As part of the adoption of the ssh process, I would like to set the > ssh process's gid equal to that of the job it is being adopted into. > > Ryan > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From keisial at gmail.com Fri May 22 09:29:16 2015 From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 22 May 2015 01:29:16 +0200 Subject: Help with debug mode needed In-Reply-To: References: , <20150520114851.eee150c3.skraw@ithnet.com> <20150520124657.1571.qmail@stuge.se> <20150520155822.8a79124a.skraw@ithnet.com> <20150520150534.GA3086@mathom.us> Message-ID: <555E6A4C.6030008@gmail.com> On 21/05/15 02:24, Eric Wedaa wrote: > All; > > I'm working on an ssh honeypot to analyze botnets, and I'm trying to find the chunk of code that specifies the following (like in Kippo) > > TIMESTAMP [HoneyPotTransport,2522,XX.XX.XX.XX] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa > TIMESTAMP [HoneyPotTransport,2522,XX.XX.XX.XX] outgoing: aes128-ctr hmac-sha1 none > TIMESTAMP [HoneyPotTransport,2522,XX.XX.XX.XX] incoming: aes128-ctr hmac-sha1 none > > I was able to find the section in sshd.c where I can log the client name and port, > and the section in auth.c where the password is cleartext, but I have no idea what I'm really looking for for finding the protocols. > > I honestly have no idea where I should really be looking. If somebody can point me in the right direction (or send a code fragment) I'd really appreciate it. I'll post a link back to the mailing list of where everyone else can find the completed code if I get some help. > > (BTW: It's live already at http://longtail.it.marist.edu and I've already found and/or analyzed 9 botnets. Having better information on who's attacking will make it easier I hope to bunch them all together). > > (And no, I'm not rising to the bait about tcpwrappers :-) It's decided and done.) I have a similar "honeypot patch" (available on request) but it doesn't include the key algos (I'd consider even more interesting the ssh client banner, though). I will certainly try out your tool. I have too many events with only a brief processing (not that there are many ip addresses?). From djm at mindrot.org Fri May 22 10:33:24 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 May 2015 10:33:24 +1000 (AEST) Subject: Weak DH primes and openssh In-Reply-To: <555DDD09.3090606@debian.org> References: <555DDD09.3090606@debian.org> Message-ID: On Thu, 21 May 2015, Matthew Vernon wrote: > Hi, > > You will be aware of https://weakdh.org/ by now, I presume; the > take-home seems to be that 1024-bit DH primes might well be too weak. > I'm wondering what (if anything!) you propose to do about this issue, > and what Debian might do for our users? I don't think much needs to be done: OpenSSH has preferred ECDH, and before that DH group-exchange with regularly refreshed modp groups for over a decade, so the diffie-hellman-group1-sha1 mode is only ever used for compatibility with legacy implementations. While it is still offered (only by the client), it is offered last in preference and will never be selected if the client and server support better options. SSH's key exchange protocol AFAIK stronger than SSL/TLS's and forcing a downgrade requires breaking both the DH exchange and the hostkey algorithm in more or less real time. We do plan on dropping diffie-hellman-group1-sha1 from the default client offer later this year. We dropped it from servers a few releases ago. As for what Debian (and other distribtors) can do: IMO the best thing is to aggressively backport recent releases of OpenSSH to older supported releases of your operating systems. We've been trying to modernise the crypto across the 6.x releases as fast as we can without breaking stuff. > openssh already prefers ECDH, which must reduce the impact somewhat, > although the main Windows client (PuTTY) doesn't support ECDH yet. But > openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which > must be considered a bit suspect? Of course RFC4253 says implementations > MUST offer these... We'll be violating a few "MUST" clauses in the 7.0 release in the interests of security, including turning off group1 by default. > The moduli file you provide has this distribution of sizes: > > size count > 1023 36 > 1535 50 > 2047 36 > 3071 31 > 4095 41 > 6143 27 > 8191 39 > > Would it be sensible to remove the <2047 moduli? Generating the larger > ones is quite time-consuming on non-specialist kit, which would seem to > argue against re-generating them on users' machines. Darren can chime in here, but I don't think anything <2047 will actually be used since he updated dh.c:dh_estimate() a few years ago. -d From dtucker at zip.com.au Fri May 22 12:27:01 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 May 2015 12:27:01 +1000 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: On Fri, May 22, 2015 at 10:33 AM, Damien Miller wrote: > > On Thu, 21 May 2015, Matthew Vernon wrote: > > > Hi, > > > > You will be aware of https://weakdh.org/ by now, I presume; the > > take-home seems to be that 1024-bit DH primes might well be too weak. > > I'm wondering what (if anything!) you propose to do about this issue, > > and what Debian might do for our users? > > I don't think much needs to be done: OpenSSH has preferred ECDH, and > before that DH group-exchange with regularly refreshed modp groups for > over a decade, My intent was to refresh the groups for every release, but for several reasons I haven't been consistent. I am currently generating a new set. > so the diffie-hellman-group1-sha1 mode is only ever used > for compatibility with legacy implementations. > > While it is still offered (only by the client), it is offered last > in preference and will never be selected if the client and server > support better options. SSH's key exchange protocol AFAIK stronger than > SSL/TLS's and forcing a downgrade requires breaking both the DH exchange > and the hostkey algorithm in more or less real time. > > We do plan on dropping diffie-hellman-group1-sha1 from the default > client offer later this year. We dropped it from servers a few releases > ago. > > As for what Debian (and other distribtors) can do: IMO the best thing is > to aggressively backport recent releases of OpenSSH to older supported > releases of your operating systems. We've been trying to modernise the > crypto across the 6.x releases as fast as we can without breaking stuff. > > > openssh already prefers ECDH, which must reduce the impact somewhat, > > although the main Windows client (PuTTY) doesn't support ECDH yet. But > > openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit > > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which > > must be considered a bit suspect? Of course RFC4253 says implementations > > MUST offer these... > Note that PuTTY does do Diffie-Hellman Group Exchange, but until very recently (ie after their 0.64 release) they didn't do the one that was actually standardized in RFC4419. OpenSSH recently removed support for that non-standard one and as a result we don't offer DHGEX to PuTTY versions <= 0.64 so they'll fall back to group14 (2k bit fix group). > We'll be violating a few "MUST" clauses in the 7.0 release in the > interests of security, including turning off group1 by default. [...] > > Would it be sensible to remove the <2047 moduli? Generating the larger > > ones is quite time-consuming on non-specialist kit, which would seem to > > argue against re-generating them on users' machines. > Currently, generating the 8kbit groups takes about 12 hours on a fairly beefy 8 core x86-64 machine. Anything slower, with fewer cores or bits would take a lot longer. Generating just the 1kbit groups takes about an hour on a 500MHz Pentium class chip of the type found in smallish x86 embedded systems. (Out of curiosity I fed the 8k candidate list to the same machine: it currently estimates it'll take 281 days). Darren can chime in here, but I don't think anything <2047 will actually > be used since he updated dh.c:dh_estimate() a few years ago. > That's only true for OpenSSH clients. PuTTY does this in their ssh.c: s->pbits = 512 << ((s->nbits - 1) / 64); which means that it'll ask for 1024, 2048 and 4906 bit groups for 128 bit, 192 bit and 256 bit ciphers respectively (ie equivalent to what OpenSSH did prior to [1], which is a lot less than current recommendations[2]. That said the development versions also have ecdh which they use in preference to DH-GEX. Anyway those older PuTTYs will be around for a while, maybe we should be removing the 1024 bit groups from the moduli file? For it to have much impact it'd need to happen on the older OpenSSH servers because the current ones don't offer DH-GEX to old PuTTY versions for the reasons above. [1] https://anongit.mindrot.org/openssh.git/commit/dh.c?id=df62d71e64d29d1054e7a53d1a801075ef70335f ) [2] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri May 22 14:06:29 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 May 2015 14:06:29 +1000 Subject: Weak DH primes and openssh In-Reply-To: <555DDD09.3090606@debian.org> References: <555DDD09.3090606@debian.org> Message-ID: On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon wrote: > > You will be aware of https://weakdh.org/ by now, I presume; the > take-home seems to be that 1024-bit DH primes might well be too weak. > I'm wondering what (if anything!) you propose to do about this issue, > and what Debian might do for our users? Would you (and any other vendors) consider generating your own moduli file for your distribution? If a few vendors did that it'd increase the diversity quite a lot and it'd stop us (well, specifically me) being the point of failure for not making updates. I have some scripts to split the screening (the CPU intensive part) up into 1 shard per CPU, which would let the whole process run in about a day on a decent sized machine. If there is any interest I can tidy them up and stick them in contrib/ or something. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From loganaden at gmail.com Fri May 22 14:25:51 2015 From: loganaden at gmail.com (Loganaden Velvindron) Date: Fri, 22 May 2015 04:25:51 +0000 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: On May 22, 2015 8:18 AM, "Darren Tucker" wrote: > > On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon wrote: > > > > You will be aware of https://weakdh.org/ by now, I presume; the > > take-home seems to be that 1024-bit DH primes might well be too weak. > > I'm wondering what (if anything!) you propose to do about this issue, > > and what Debian might do for our users? > > > Would you (and any other vendors) consider generating your own moduli file > for your distribution? If a few vendors did that it'd increase the > diversity quite a lot and it'd stop us (well, specifically me) being the > point of failure for not making updates. > > I have some scripts to split the screening (the CPU intensive part) up into > 1 shard per CPU, which would let the whole process run in about a day on a > decent sized machine. If there is any interest I can tidy them up and > stick them in contrib/ or something. Are the scripts public ? > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Fri May 22 15:15:02 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 22 May 2015 15:15:02 +1000 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: On Fri, May 22, 2015 at 2:25 PM, Loganaden Velvindron wrote: [...] > > I have some scripts to split the screening (the CPU intensive part) up into > > 1 shard per CPU, which would let the whole process run in about a day on a > > decent sized machine. If there is any interest I can tidy them up and > > stick them in contrib/ or something. > > Are the scripts public ? Not currently but they could be with a bit of tidying up, which is why I'm asking. Most of the things that make it practical rather than a pain in the neck to manage have been added to ssh-keygen (eg -j/-J to start at a specified line and process a specified number of lines, checkpoints, and where possible completion time estimates). The rest is just some Makefile and a wrapper script. Anyway, it sounds like there is at least some interest so I'll round it up. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dwm37 at cam.ac.uk Sat May 23 00:30:43 2015 From: dwm37 at cam.ac.uk (David McBride) Date: Fri, 22 May 2015 15:30:43 +0100 Subject: Weak DH primes and openssh Message-ID: <555F3D93.7050307@cam.ac.uk> On Fri, May 22, 2015 at 12:27:01, Darren Tucker wrote: > Note that PuTTY does do Diffie-Hellman Group Exchange, but until very > recently (ie after their 0.64 release) they didn't do the one that was > actually standardized in RFC4419. OpenSSH recently removed support for > that non-standard one and as a result we don't offer DHGEX to PuTTY > versions <= 0.64 so they'll fall back to group14 (2k bit fix group). I think this is wrong. This commit [0] from 2005 appears to show the addition of diffie-hellman-group-exchange-sha256 support to PuTTY. I've also just successfully connected to a local test OpenSSH server (v6.7p1, as packaged by Debian) with only diffie-hellman-group-exchange-sha256 enabled with an older release of PuTTY (0.63) without any issue. Indeed, PuTTY explicitly reported in its event log that it performed key-exchange using Diffie-Hellman group exchange and SHA-256, so I'm quite sure this is working! Unless there's more than one key-exchange mechanism going by the name diffie-hellman-group-exchange-sha256? Kind regards, David [0] http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commit;h=91319142781a69cb16053c180870878749477012 -- David McBride Unix Specialist, University Information Services From dkg at fifthhorseman.net Sat May 23 02:42:37 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 May 2015 12:42:37 -0400 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: <87bnhcpnr6.fsf@alice.fifthhorseman.net> On Thu 2015-05-21 20:33:24 -0400, Damien Miller wrote: > On Thu, 21 May 2015, Matthew Vernon wrote: >> openssh already prefers ECDH, which must reduce the impact somewhat, >> although the main Windows client (PuTTY) doesn't support ECDH yet. But >> openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit >> group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which >> must be considered a bit suspect? Of course RFC4253 says implementations >> MUST offer these... > > We'll be violating a few "MUST" clauses in the 7.0 release in the > interests of security, including turning off group1 by default. Is it worth trying to update the RFC to change these MUSTs for something better? --dkg From dkg at fifthhorseman.net Sat May 23 05:47:15 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 May 2015 15:47:15 -0400 Subject: problems with https://anongit.mindrot.org/openssh.git Message-ID: <87twv4o0n0.fsf@alice.fifthhorseman.net> hi OpenSSH folks-- cloning via https appears to take a very long time: 0 dkg at alice:/tmp/cdtemp.SrJtFK$ git clone https://anongit.mindrot.org/openssh.git Cloning into 'openssh'... (this hangs for several minutes, i haven't seen it complete yet) From an already-checked-out (but not recently-updated) version, i see: 0 dkg at alice:~/src/openssh/openssh$ git remote update Fetching origin error: Unable to find 3185462905589d5db237d97ac5bc2f131844da64 under https://anongit.mindrot.org/openssh.git Cannot obtain needed blob 3185462905589d5db237d97ac5bc2f131844da64 while processing commit 0882332616e4f0272c31cc47bf2018f9cb258a4e. error: fetch failed. error: Could not fetch origin 1 dkg at alice:~/src/openssh/openssh$ So i think something is wrong with the git https backend on anongit.mindrot.org. Let me know if i can provide more useful debugging information. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat May 23 06:22:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 May 2015 16:22:13 -0400 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: <87r3q8nz0q.fsf@alice.fifthhorseman.net> On Fri 2015-05-22 00:06:29 -0400, Darren Tucker wrote: > On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon wrote: >> >> You will be aware of https://weakdh.org/ by now, I presume; the >> take-home seems to be that 1024-bit DH primes might well be too weak. >> I'm wondering what (if anything!) you propose to do about this issue, >> and what Debian might do for our users? > > Would you (and any other vendors) consider generating your own moduli file > for your distribution? If a few vendors did that it'd increase the > diversity quite a lot and it'd stop us (well, specifically me) being the > point of failure for not making updates. (thanks for making the recent moduli update, Darren!) This is an interesting proposal as a way to increase group diversity, but it also creates a non-obvious fingerprinting channel. That is, distro-specific groups would provide a way that someone scanning to find out what distro is in use can make a more accurate guess based on the primes offered. I grant that debian's current patches that add the debian revision themselves provide a fingerprinting mechanism, but those can be disabled on Debian with "DebianBanner no" in sshd_config. We'd want to make sure that distro-specific moduli don't re-introduce fingerprinting for operators who want to hide their choice of distro. --dkg PS Darren, has there been any attempt at generating primality proofs for the values in ./moduli, as opposed to 100 rounds of Miller-Rabin? It would be a shame for a pseudoprime to slip in, however unlikely that would be. From djm at mindrot.org Sat May 23 20:16:04 2015 From: djm at mindrot.org (Damien Miller) Date: Sat, 23 May 2015 20:16:04 +1000 (AEST) Subject: Weak DH primes and openssh In-Reply-To: <87r3q8nz0q.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <87r3q8nz0q.fsf@alice.fifthhorseman.net> Message-ID: On Fri, 22 May 2015, Daniel Kahn Gillmor wrote: > PS Darren, has there been any attempt at generating primality proofs for > the values in ./moduli, as opposed to 100 rounds of Miller-Rabin? It > would be a shame for a pseudoprime to slip in, however unlikely that > would be. I looked at it a few years ago, but couldn't figure out a way to generate provable safe primes. I'd love someone to get this working. AFAIK the number of Miller-Rabin tests we do is many times more than OpenSSL's baseline BN_is_prime() false positive rate of 2^-80. -d From emailgrant at gmail.com Sun May 24 01:14:08 2015 From: emailgrant at gmail.com (Grant) Date: Sat, 23 May 2015 08:14:08 -0700 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: > Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting? weakdh.org/sysadmin.html recommends adding: KexAlgorithms curve25519-sha256 at libssh.org But this thread makes it sound as if it's not necessary. Can anyone confirm? Personally I'm on openssh-6.7. - Grant > You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. > I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? > > openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... > > The moduli file you provide has this distribution of sizes: > > size count > 1023 36 > 1535 50 > 2047 36 > 3071 31 > 4095 41 > 6143 27 > 8191 39 > > Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist kit, which would seem to argue against re-generating them on users' machines. From de.techno at gmail.com Sun May 24 02:56:05 2015 From: de.techno at gmail.com (dE) Date: Sat, 23 May 2015 22:26:05 +0530 Subject: X11 forwarding not working. In-Reply-To: <555FF880.7050704@gmail.com> References: <555FF880.7050704@gmail.com> Message-ID: <5560B125.20107@gmail.com> Hi! I'm having a difficult time getting X11 forwarding to work. Since I've read the docs completely about this, this must be an SSH bug which is likely because I'm using Gentoo as the SSH server. When trying to forward X11 connections, I get X11 connection rejected because of wrong authentication. kwrite: cannot connect to X server XXXXXXXXX:10.0 Using command ssh -Y -p 1111 -4 -i testkey test at 127.0.0.1 I'm not using any X11 library build with ipv6 support. I tried building the relevant library (after seeing the dependency of the X11 application) with ipv6 support, but it was of no help. Of course first I did not use -4. In the server, I've tried disabling ipv6 support. The following exists in sshd_config -- X11UseLocalhost no X11Forwarding yes I've tried xhost + on the client and the server (although it wont help on the server). Thank you for any assistance. From dtucker at zip.com.au Sun May 24 08:06:32 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 May 2015 08:06:32 +1000 Subject: X11 forwarding not working. In-Reply-To: <5560B125.20107@gmail.com> References: <555FF880.7050704@gmail.com> <5560B125.20107@gmail.com> Message-ID: On Sun, May 24, 2015 at 2:56 AM, dE wrote: > > I'm having a difficult time getting X11 forwarding to work. > > Since I've read the docs completely about this, this must be an SSH bug > which is likely because I'm using Gentoo as the SSH server. > [...] I suspect the problem is that you did not have xauth in your path when you built OpenSSH and thus sshd does not know where to find it. Try adding "XAuthLocation /path/to/your/xauth" to your sshd_config and restart sshd. If that doesn't help then please post the debug output from both client and server (ie /path/to/sshd -ddd and ssh -vvv) and we might be able to figure out what's going on. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sun May 24 09:20:27 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 May 2015 09:20:27 +1000 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: On Sun, May 24, 2015 at 1:14 AM, Grant wrote: > > Can this be addressed in ssh_config/sshd_config with the KexAlgorithms > setting? > > weakdh.org/sysadmin.html recommends adding: > > KexAlgorithms curve25519-sha256 at libssh.org > > But this thread makes it sound as if it's not necessary. Can anyone > confirm? Personally I'm on openssh-6.7. > There's 3 pieces of advice for OpenSSH there, and IMO two of them are bad including that one. Firstly the somewhat reasonable one: remove diffie-hellman-group1-sha1 from KexAlgorithms, ie KexAlgorithms curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 That still means it'll break any implementation that doesn't do at least group14. I don't know of one, but it's possible. Of the other two suggestions: - having just curve25519-sha256 at libssh.org will break interop with anything that doesn't support it (and many don't) and doesn't buy you much since on the client side the stronger methods will get used by preference. - regenerating the moduli file is in itself not a bad idea, but the instructions given will result in a file that has only 2kbit groups, which will result in significantly *weaker* groups being used in many cases (eg OpenSSH will typically ask for 3kbit to 8kbit groups. The other possible action that IMO would be reasonable but is not listed: remove all of the 1kbit and 1.5kbit groups from the moduli file (or omitting them when regenerating). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sun May 24 09:24:48 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 May 2015 09:24:48 +1000 Subject: Weak DH primes and openssh In-Reply-To: <555F3D93.7050307@cam.ac.uk> References: <555F3D93.7050307@cam.ac.uk> Message-ID: On Sat, May 23, 2015 at 12:30 AM, David McBride wrote: > On Fri, May 22, 2015 at 12:27:01, Darren Tucker > wrote: > > > Note that PuTTY does do Diffie-Hellman Group Exchange, but until very > > recently (ie after their 0.64 release) they didn't do the one that was > > actually standardized in RFC4419. OpenSSH recently removed support for > > that non-standard one and as a result we don't offer DHGEX to PuTTY > > versions <= 0.64 so they'll fall back to group14 (2k bit fix group). > > I think this is wrong. > > This commit [0] from 2005 appears to show the addition of > diffie-hellman-group-exchange-sha256 support to PuTTY. > You're right, thanks for pointing this out. When I looked at it I was specifically looking at group-exchange-sha1 (because that was the thing using the deprecated format) and overlooked sha256. That does mean that there's a stronger case for removing 1kbit and 1.5kbit groups from the moduli file because that would result in stronger groups being used for versions of PuTTY from then until 0.64, which is the current release as I write this. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From de.techno at gmail.com Sun May 24 15:44:44 2015 From: de.techno at gmail.com (dE .) Date: Sun, 24 May 2015 11:14:44 +0530 Subject: X11 forwarding not working. In-Reply-To: References: <555FF880.7050704@gmail.com> <5560B125.20107@gmail.com> Message-ID: On Sun, May 24, 2015 at 3:36 AM, Darren Tucker wrote: > On Sun, May 24, 2015 at 2:56 AM, dE wrote: >> >> I'm having a difficult time getting X11 forwarding to work. >> >> Since I've read the docs completely about this, this must be an SSH bug >> which is likely because I'm using Gentoo as the SSH server. >> > [...] > > I suspect the problem is that you did not have xauth in your path when you > built OpenSSH and thus sshd does not know where to find it. Try adding > "XAuthLocation /path/to/your/xauth" to your sshd_config and restart sshd. > > If that doesn't help then please post the debug output from both client > and server (ie /path/to/sshd -ddd and ssh -vvv) and we might be able to > figure out what's going on. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 51: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to xxxx.xxxx.xxxx [123.123.123.123] port 111. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key" as a RSA1 public key debug1: identity file /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key type -1 debug1: identity file /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1-hpn14v5 debug1: match: OpenSSH_6.7p1-hpn14v5 pat OpenSSH* debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [xxxx.xxxx.xxxx]:111 debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" from file "/home/kiosk/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/kiosk/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received 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 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com, ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, aes128-gcm at openssh.com debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, aes128-gcm at openssh.com debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1-etm at openssh.com debug1: kex: server->client aes128-ctr hmac-sha1-etm at openssh.com none debug2: mac_setup: found hmac-sha1-etm at openssh.com debug1: kex: client->server aes128-ctr hmac-sha1-etm at openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA c4:67:d3:7d:93:af:d8:23:e4:1f:9b:66:9b:c5:b8:13 debug3: put_host_port: [xxxx.xxxx.xxxx]:111 debug3: put_host_port: [xxxx.xxxx.xxxx]:111 debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" from file "/home/kiosk/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/kiosk/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" from file "/home/kiosk/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/kiosk/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '[xxxx.xxxx.xxxx]:111' is known and matches the ECDSA host key. debug1: Found key in /home/kiosk/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key ((nil)), explicit debug1: Authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey: RSA 97:5a:4d:07:ee:9a:e3:e9:8f:4d:f3:8b:7b:4f:c4:57 debug2: we sent a publickey packet, wait for reply debug1: Authentication succeeded (publickey). Authenticated to xxxx.xxxx.xxxx ([xxxx.xxxx.xxxx]:111). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug1: SSH2_MSG_KEXINIT received debug1: SSH2_MSG_KEXINIT sent 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 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com, ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, aes128-gcm at openssh.com debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, aes128-gcm at openssh.com debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1-etm at openssh.com debug1: kex: server->client aes128-ctr hmac-sha1-etm at openssh.com none debug2: mac_setup: found hmac-sha1-etm at openssh.com debug1: kex: client->server aes128-ctr hmac-sha1-etm at openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA c4:67:d3:7d:93:af:d8:23:e4:1f:9b:66:9b:c5:b8:13 debug3: put_host_port: [xxxx.xxxx.xxxx]:111 debug3: put_host_port: [xxxx.xxxx.xxxx]:111 debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" from file "/home/kiosk/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/kiosk/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" from file "/home/kiosk/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/kiosk/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '[xxxx.xxxx.xxxx]:111' is known and matches the ECDSA host key. debug1: Found key in /home/kiosk/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: set_newkeys: rekeying debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: set_newkeys: rekeying debug1: SSH2_MSG_NEWKEYS received debug2: callback start debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 1 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env XDG_VTNR debug3: Ignored env XDG_SESSION_ID debug3: Ignored env DBUS_STARTER_ADDRESS debug3: Ignored env GPG_AGENT_INFO debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env XDG_MENU_PREFIX debug3: Ignored env VTE_VERSION debug3: Ignored env WINDOWID debug3: Ignored env GNOME_KEYRING_CONTROL debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env SESSION_MANAGER debug3: Ignored env USERNAME debug3: Ignored env PATH debug3: Ignored env DESKTOP_SESSION debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env GDM_LANG debug3: Ignored env GDMSESSION debug3: Ignored env DBUS_STARTER_BUS_TYPE debug3: Ignored env HOME debug3: Ignored env XDG_SEAT debug3: Ignored env SHLVL debug3: Ignored env GNOME_DESKTOP_SESSION_ID debug3: Ignored env LOGNAME debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env LESSOPEN debug3: Ignored env WINDOWPATH debug3: Ignored env XDG_RUNTIME_DIR debug3: Ignored env DISPLAY debug3: Ignored env COLORTERM debug3: Ignored env XAUTHORITY debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: X11 forwarding request accepted on channel 0 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 87380 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Sun May 24 10:53:28 2015 from x.x.x.x de at DESKTOP_MINER ~ $ kwrite debug1: client_input_channel_open: ctype x11 rchan 3 win 87380 max 16384 debug1: client_request_x11: request from 127.0.0.1 46768 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug2: X11 rejected 1 i0/o0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: send eof debug2: channel 1: input drain -> closed debug2: channel 1: write failed debug2: channel 1: close_write debug2: channel 1: output open -> closed debug2: X11 closed 1 i3/o3 debug2: channel 1: send close debug2: channel 1: rcvd close debug2: channel 1: is dead debug2: channel 1: garbage collecting debug1: channel 1: free: x11, nchannels 2 debug3: channel 1: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) #1 x11 (t7 r3 i3/0 o3/0 fd 7/7 cc -1) kwrite: cannot connect to X server DESKTOP_MINER:11.0 Ok, got it. "X11 connection uses different authentication protocol." Please suggest. I'm also looking at it on my end. From de.techno at gmail.com Sun May 24 16:05:04 2015 From: de.techno at gmail.com (dE .) Date: Sun, 24 May 2015 11:35:04 +0530 Subject: X11 forwarding not working. In-Reply-To: References: <555FF880.7050704@gmail.com> <5560B125.20107@gmail.com> Message-ID: Ok, got it further. If X11 forwarding is in use, it will receive the "proto cookie" pair in its standard input Now, solved. On Sun, May 24, 2015 at 11:14 AM, dE . wrote: > On Sun, May 24, 2015 at 3:36 AM, Darren Tucker wrote: > >> On Sun, May 24, 2015 at 2:56 AM, dE wrote: >>> >>> I'm having a difficult time getting X11 forwarding to work. >>> >>> Since I've read the docs completely about this, this must be an SSH bug >>> which is likely because I'm using Gentoo as the SSH server. >>> >> [...] >> >> I suspect the problem is that you did not have xauth in your path when >> you built OpenSSH and thus sshd does not know where to find it. Try adding >> "XAuthLocation /path/to/your/xauth" to your sshd_config and restart sshd. >> >> If that doesn't help then please post the debug output from both client >> and server (ie /path/to/sshd -ddd and ssh -vvv) and we might be able to >> figure out what's going on. >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 >> Good judgement comes with experience. Unfortunately, the experience >> usually comes from bad judgement. >> > > OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 51: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to xxxx.xxxx.xxxx [123.123.123.123] port 111. > debug1: Connection established. > debug3: Incorrect RSA1 identifier > debug3: Could not load > "/run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key" as a RSA1 > public key > debug1: identity file > /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key type -1 > debug1: identity file > /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.4 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_6.7p1-hpn14v5 > debug1: match: OpenSSH_6.7p1-hpn14v5 pat OpenSSH* > debug2: fd 3 setting O_NONBLOCK > debug3: put_host_port: [xxxx.xxxx.xxxx]:111 > debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" > from file "/home/kiosk/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file > /home/kiosk/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ecdsa-sha2-nistp256-cert-v01 at openssh.com, > ecdsa-sha2-nistp384-cert-v01 at openssh.com, > ecdsa-sha2-nistp521-cert-v01 at openssh.com > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > 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 > debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com, > ecdsa-sha2-nistp384-cert-v01 at openssh.com, > ecdsa-sha2-nistp521-cert-v01 at openssh.com > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, > ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com, > ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, > hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com > ,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, > hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, > umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, > hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com > ,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, > hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, > umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 > debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com > ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, > aes128-gcm at openssh.com > debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com > ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, > aes128-gcm at openssh.com > debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com > ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 > debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com > ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_setup: found hmac-sha1-etm at openssh.com > debug1: kex: server->client aes128-ctr hmac-sha1-etm at openssh.com none > debug2: mac_setup: found hmac-sha1-etm at openssh.com > debug1: kex: client->server aes128-ctr hmac-sha1-etm at openssh.com none > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: Server host key: ECDSA > c4:67:d3:7d:93:af:d8:23:e4:1f:9b:66:9b:c5:b8:13 > debug3: put_host_port: [xxxx.xxxx.xxxx]:111 > debug3: put_host_port: [xxxx.xxxx.xxxx]:111 > debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" > from file "/home/kiosk/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file > /home/kiosk/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" > from file "/home/kiosk/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file > /home/kiosk/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug1: Host '[xxxx.xxxx.xxxx]:111' is known and matches the ECDSA host > key. > debug1: Found key in /home/kiosk/.ssh/known_hosts:1 > debug1: ssh_ecdsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key > ((nil)), explicit > debug1: Authentications that can continue: publickey,keyboard-interactive > debug3: start over, passed a different list publickey,keyboard-interactive > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Trying private key: > /run/media/kiosk/71ad235a-3765-4a80-9971-6b602e8e9c28/my.key > debug1: read PEM private key done: type RSA > debug3: sign_and_send_pubkey: RSA > 97:5a:4d:07:ee:9a:e3:e9:8f:4d:f3:8b:7b:4f:c4:57 > debug2: we sent a publickey packet, wait for reply > debug1: Authentication succeeded (publickey). > Authenticated to xxxx.xxxx.xxxx ([xxxx.xxxx.xxxx]:111). > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Requesting no-more-sessions at openssh.com > debug1: Entering interactive session. > debug1: SSH2_MSG_KEXINIT received > debug1: SSH2_MSG_KEXINIT sent > 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 > debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com, > ecdsa-sha2-nistp384-cert-v01 at openssh.com, > ecdsa-sha2-nistp521-cert-v01 at openssh.com > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, > ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com, > ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, > hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com > ,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, > hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, > umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, > hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com > ,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, > hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, > umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 > debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com > ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, > aes128-gcm at openssh.com > debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com > ,cast128-cbc,blowfish-cbc,arcfour128,aes128-cbc,aes128-ctr, > aes128-gcm at openssh.com > debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com > ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 > debug2: kex_parse_kexinit: hmac-sha1-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,umac-64-etm at openssh.com > ,hmac-md5-96,hmac-ripemd160,hmac-sha1-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_setup: found hmac-sha1-etm at openssh.com > debug1: kex: server->client aes128-ctr hmac-sha1-etm at openssh.com none > debug2: mac_setup: found hmac-sha1-etm at openssh.com > debug1: kex: client->server aes128-ctr hmac-sha1-etm at openssh.com none > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: Server host key: ECDSA > c4:67:d3:7d:93:af:d8:23:e4:1f:9b:66:9b:c5:b8:13 > debug3: put_host_port: [xxxx.xxxx.xxxx]:111 > debug3: put_host_port: [xxxx.xxxx.xxxx]:111 > debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" > from file "/home/kiosk/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file > /home/kiosk/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "[xxxx.xxxx.xxxx]:111" > from file "/home/kiosk/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file > /home/kiosk/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug1: Host '[xxxx.xxxx.xxxx]:111' is known and matches the ECDSA host > key. > debug1: Found key in /home/kiosk/.ssh/known_hosts:1 > debug1: ssh_ecdsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: set_newkeys: rekeying > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: set_newkeys: rekeying > debug1: SSH2_MSG_NEWKEYS received > debug2: callback start > debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null > debug1: Requesting X11 forwarding with authentication spoofing. > debug2: channel 0: request x11-req confirm 1 > debug2: fd 3 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x10 > debug2: client_session2_setup: id 0 > debug2: channel 0: request pty-req confirm 1 > debug1: Sending environment. > debug3: Ignored env XDG_VTNR > debug3: Ignored env XDG_SESSION_ID > debug3: Ignored env DBUS_STARTER_ADDRESS > debug3: Ignored env GPG_AGENT_INFO > debug3: Ignored env TERM > debug3: Ignored env SHELL > debug3: Ignored env XDG_MENU_PREFIX > debug3: Ignored env VTE_VERSION > debug3: Ignored env WINDOWID > debug3: Ignored env GNOME_KEYRING_CONTROL > debug3: Ignored env USER > debug3: Ignored env LS_COLORS > debug3: Ignored env SSH_AUTH_SOCK > debug3: Ignored env SESSION_MANAGER > debug3: Ignored env USERNAME > debug3: Ignored env PATH > debug3: Ignored env DESKTOP_SESSION > debug3: Ignored env PWD > debug1: Sending env LANG = en_US.UTF-8 > debug2: channel 0: request env confirm 0 > debug3: Ignored env GDM_LANG > debug3: Ignored env GDMSESSION > debug3: Ignored env DBUS_STARTER_BUS_TYPE > debug3: Ignored env HOME > debug3: Ignored env XDG_SEAT > debug3: Ignored env SHLVL > debug3: Ignored env GNOME_DESKTOP_SESSION_ID > debug3: Ignored env LOGNAME > debug3: Ignored env DBUS_SESSION_BUS_ADDRESS > debug3: Ignored env LESSOPEN > debug3: Ignored env WINDOWPATH > debug3: Ignored env XDG_RUNTIME_DIR > debug3: Ignored env DISPLAY > debug3: Ignored env COLORTERM > debug3: Ignored env XAUTHORITY > debug3: Ignored env _ > debug2: channel 0: request shell confirm 1 > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: X11 forwarding request accepted on channel 0 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: PTY allocation request accepted on channel 0 > debug2: channel 0: rcvd adjust 87380 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: shell request accepted on channel 0 > Last login: Sun May 24 10:53:28 2015 from x.x.x.x > de at DESKTOP_MINER ~ $ kwrite > debug1: client_input_channel_open: ctype x11 rchan 3 win 87380 max 16384 > debug1: client_request_x11: request from 127.0.0.1 46768 > debug2: fd 7 setting O_NONBLOCK > debug3: fd 7 is O_NONBLOCK > debug1: channel 1: new [x11] > debug1: confirm x11 > debug2: X11 connection uses different authentication protocol. > X11 connection rejected because of wrong authentication. > debug2: X11 rejected 1 i0/o0 > debug2: channel 1: read failed > debug2: channel 1: close_read > debug2: channel 1: input open -> drain > debug2: channel 1: ibuf empty > debug2: channel 1: send eof > debug2: channel 1: input drain -> closed > debug2: channel 1: write failed > debug2: channel 1: close_write > debug2: channel 1: output open -> closed > debug2: X11 closed 1 i3/o3 > debug2: channel 1: send close > debug2: channel 1: rcvd close > debug2: channel 1: is dead > debug2: channel 1: garbage collecting > debug1: channel 1: free: x11, nchannels 2 > debug3: channel 1: status: The following connections are open: > #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) > #1 x11 (t7 r3 i3/0 o3/0 fd 7/7 cc -1) > > kwrite: cannot connect to X server DESKTOP_MINER:11.0 > > Ok, got it. > > "X11 connection uses different authentication protocol." > > Please suggest. I'm also looking at it on my end. > From bolte.felix at gmail.com Sun May 24 19:16:53 2015 From: bolte.felix at gmail.com (Felix Bolte) Date: Sun, 24 May 2015 11:16:53 +0200 Subject: [PATCH] sshd: make "-c" option usable Message-ID: please see my pull request on github (patch attached as well to this mail): > https://github.com/openssh/openssh-portable/pull/21 thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sshd-make-c-option-usable.patch Type: text/x-patch Size: 569 bytes Desc: not available URL: From dtucker at zip.com.au Sun May 24 21:06:33 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 May 2015 21:06:33 +1000 Subject: [PATCH] sshd: make "-c" option usable In-Reply-To: References: Message-ID: On Sun, May 24, 2015 at 7:16 PM, Felix Bolte wrote: > please see my pull request on github > (patch attached as well to this mail): > > > https://github.com/openssh/openssh-portable/pull/21 > Thanks! Looks like it's missing in OpenBSD too, so we need to apply it there first. Damien? http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.372&r2=1.373&f=h -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kasperd at kdxdx.23.may.2015.kasperd.net Sun May 24 21:19:13 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Sun, 24 May 2015 13:19:13 +0200 Subject: Name based SSH proxy In-Reply-To: <20150523124206.GA3538@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> Message-ID: <20150524111913.GA3571@colin.search.kasperd.net> On 23/05/15 14.42, Kasper Dupont wrote: > I am working on a proxy which can be hosted on a single > IP address and dispatch requests to different backends > depending on which hostname the client used to connect to > this IP address. > > Currently such a proxy can be build to support HTTP, HTTPS, > SMTP, and DNS. However SSH support is impossible due to > the ssh client not sending the information such a proxy > would need. > > I am not the first to want such a proxy: > http://serverfault.com/q/34552/214507 > However my searches only found people talking about it, > and nobody doing anything about it. > > I have attached a tiny patch for the openssh-client, which > I believe does everything openssh would need to do in order > to support this kind of proxies. > > What are your thoughts on the attached patch? > > Rationale behind the design of the patch: > A name based SSH proxy will need to accept connections from > clients and based on data send by the client choose a > backend server to connect to. > > The proxy will not be able to forward the version > identification from the backend to the client until after > it has connected to the backend. Thus the proxy will need > to extract the hostname from the data send by the client > before any version identification has been send in the > other direction. > > This leaves the version identification send from client > to server as the only place such a proxy could possibly > extract the hostname from. Thus the patch would have to > extend the format of the version identification to include > a hostname. > > The version identification contains a comments field > which at the moment is a free form field send by client > and ignored by server. The intended purpose of this field > is to aid in debugging, thus it just needed to be huamn > redable. > > Replacing the comments field with JSON formatted data will > allow it to serve both purposes. I picked JSON because it > is extensible and very simple. > > The change amounts to modifying two lines of code in > send_client_banner and passing the hostname as function > argument where it is now necessary. No server side changes > are needed. I have put a copy of the patch here: http://share.kasperd.net/openssh-6.6p1-sni.patch And an example of how a proxy using this feature could be implemented here: http://share.kasperd.net/ssh-sni.py -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dkg at fifthhorseman.net Sun May 24 23:40:33 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 24 May 2015 09:40:33 -0400 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> <87r3q8nz0q.fsf@alice.fifthhorseman.net> Message-ID: <87617inlf2.fsf@alice.fifthhorseman.net> On Sat 2015-05-23 06:16:04 -0400, Damien Miller wrote: > On Fri, 22 May 2015, Daniel Kahn Gillmor wrote: > >> PS Darren, has there been any attempt at generating primality proofs for >> the values in ./moduli, as opposed to 100 rounds of Miller-Rabin? It >> would be a shame for a pseudoprime to slip in, however unlikely that >> would be. > > I looked at it a few years ago, but couldn't figure out a way to > generate provable safe primes. I'd love someone to get this working. I've generated primality proofs for comparably large primes (and safe primes, at that) with Primo [0] for my work on TLS [1], but Primo is not free software; the proofs are complex to read and parse (and i know of no software other than Primo to verify them directly at the moment, which makes it a bit of a circular argument); and it takes quite a bit of compute power to produce them, especially for larger primes. I have not run Primo against any of the moduli shipped with OpenSSH. > AFAIK the number of Miller-Rabin tests we do is many times more than > OpenSSL's baseline BN_is_prime() false positive rate of 2^-80. Yep, but then we're all just relying on your (or Darren's) claims of Miller-Rabin tests, i guess. I trust you guys, but as Darren points out, it's a drag to have to be a single point of failure on something like this where corroboration would be better. In that spirit, i've just tested the moduli (both the 2012 versions and the recent update), using gmp's mpz_probab_prime_p() [2] with 400 rounds of randomized Miller-Rabin [3] on each modulus p and on q=(p-1)/2. the test is pretty straightforward in python, if anyone else wants to try an independent verification (make sure you've got the gmpy2 python module installed): ------------------- #!/usr/bin/python import gmpy2 f = open('/etc/ssh/moduli') for r in f: if len(r) == 0 or r[0] == '#': continue p = gmpy2.mpz('0x' + r.split(' ')[6]) q = (p-1)//2 if 2*q+1 != p: print("something is terribly wrong with", p) continue if gmpy2.is_prime(p, 400): if gmpy2.is_prime(q, 400): print('OK') else: print("q is bad for", z) else: print("p is bad for", z) -------------------- It should print out nothing but "OK"s, one for each line, though it may take several hours, depending on the speed of your CPU (someone who wants to parallelize the above code shouldn't have a hard time doing so, which would speed it up a lot on a multi-core machine). It produced all "OKs" for me :) Regards, --dkg [0] http://www.ellipsa.eu/public/primo/primo.html [1] https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ [2] https://gmplib.org/manual/Number-Theoretic-Functions.html#Number-Theoretic-Functions [3] https://gmplib.org/manual/Prime-Testing-Algorithm.html#Prime-Testing-Algorithm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From kasperd at kdxdx.23.may.2015.kasperd.net Sat May 23 22:42:06 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Sat, 23 May 2015 14:42:06 +0200 Subject: Name based SSH proxy Message-ID: <20150523124206.GA3538@colin.search.kasperd.net> I am working on a proxy which can be hosted on a single IP address and dispatch requests to different backends depending on which hostname the client used to connect to this IP address. Currently such a proxy can be build to support HTTP, HTTPS, SMTP, and DNS. However SSH support is impossible due to the ssh client not sending the information such a proxy would need. I am not the first to want such a proxy: http://serverfault.com/q/34552/214507 However my searches only found people talking about it, and nobody doing anything about it. I have attached a tiny patch for the openssh-client, which I believe does everything openssh would need to do in order to support this kind of proxies. What are your thoughts on the attached patch? Rationale behind the design of the patch: A name based SSH proxy will need to accept connections from clients and based on data send by the client choose a backend server to connect to. The proxy will not be able to forward the version identification from the backend to the client until after it has connected to the backend. Thus the proxy will need to extract the hostname from the data send by the client before any version identification has been send in the other direction. This leaves the version identification send from client to server as the only place such a proxy could possibly extract the hostname from. Thus the patch would have to extend the format of the version identification to include a hostname. The version identification contains a comments field which at the moment is a free form field send by client and ignored by server. The intended purpose of this field is to aid in debugging, thus it just needed to be huamn redable. Replacing the comments field with JSON formatted data will allow it to serve both purposes. I picked JSON because it is extensible and very simple. The change amounts to modifying two lines of code in send_client_banner and passing the hostname as function argument where it is now necessary. No server side changes are needed. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); -------------- next part -------------- diff -up openssh-6.6p1/roaming_client.c.original openssh-6.6p1/roaming_client.c --- openssh-6.6p1/roaming_client.c.original 2014-01-10 00:58:53.000000000 +0100 +++ openssh-6.6p1/roaming_client.c 2015-05-23 12:58:12.193450191 +0200 @@ -147,7 +147,7 @@ roaming_resume(void) resume_in_progress = 1; /* Exchange banners */ - ssh_exchange_identification(timeout_ms); + ssh_exchange_identification(timeout_ms, ""); packet_set_nonblocking(); /* Send a kexinit message with resume at appgate.com as only kex algo */ diff -up openssh-6.6p1/sshconnect.c.original openssh-6.6p1/sshconnect.c --- openssh-6.6p1/sshconnect.c.original 2015-05-23 11:56:55.235217137 +0200 +++ openssh-6.6p1/sshconnect.c 2015-05-23 13:43:41.426983727 +0200 @@ -515,12 +515,13 @@ ssh_connect(const char *host, struct add } static void -send_client_banner(int connection_out, int minor1) +send_client_banner(int connection_out, int minor1, const char *host) { /* Send our own protocol version identification. */ if (compat20) { - xasprintf(&client_version_string, "SSH-%d.%d-%.100s\r\n", - PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION); + xasprintf(&client_version_string, + "SSH-%d.%d-%.100s {\"SNI\": \"%.133s\"}\r\n", + PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION, host); } else { xasprintf(&client_version_string, "SSH-%d.%d-%.100s\n", PROTOCOL_MAJOR_1, minor1, SSH_VERSION); @@ -537,7 +538,7 @@ send_client_banner(int connection_out, i * identification string. */ void -ssh_exchange_identification(int timeout_ms) +ssh_exchange_identification(int timeout_ms, const char *host) { char buf[256], remote_version[256]; /* must be same size! */ int remote_major, remote_minor, mismatch; @@ -559,7 +560,7 @@ ssh_exchange_identification(int timeout_ */ if (options.protocol == SSH_PROTO_2) { enable_compat20(); - send_client_banner(connection_out, 0); + send_client_banner(connection_out, 0, host); client_banner_sent = 1; } @@ -672,7 +673,7 @@ ssh_exchange_identification(int timeout_ logit("Server version \"%.100s\" uses unsafe RSA signature " "scheme; disabling use of RSA keys", remote_version); if (!client_banner_sent) - send_client_banner(connection_out, minor1); + send_client_banner(connection_out, minor1, host); chop(server_version_string); } @@ -1286,7 +1287,7 @@ ssh_login(Sensitive *sensitive, const ch lowercase(host); /* Exchange protocol version identification strings with the server. */ - ssh_exchange_identification(timeout_ms); + ssh_exchange_identification(timeout_ms, host); /* Put the connection into non-blocking mode. */ packet_set_nonblocking(); diff -up openssh-6.6p1/sshconnect.h.original openssh-6.6p1/sshconnect.h --- openssh-6.6p1/sshconnect.h.original 2013-10-17 02:47:24.000000000 +0200 +++ openssh-6.6p1/sshconnect.h 2015-05-23 12:57:16.129172189 +0200 @@ -39,7 +39,7 @@ void ssh_kill_proxy_command(void); void ssh_login(Sensitive *, const char *, struct sockaddr *, u_short, struct passwd *, int); -void ssh_exchange_identification(int); +void ssh_exchange_identification(int, const char *); int verify_host_key(char *, struct sockaddr *, Key *); From djm at mindrot.org Mon May 25 09:21:34 2015 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 May 2015 09:21:34 +1000 (AEST) Subject: Weak DH primes and openssh In-Reply-To: <87617inlf2.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <87r3q8nz0q.fsf@alice.fifthhorseman.net> <87617inlf2.fsf@alice.fifthhorseman.net> Message-ID: On Sun, 24 May 2015, Daniel Kahn Gillmor wrote: > Yep, but then we're all just relying on your (or Darren's) claims of > Miller-Rabin tests, i guess. I trust you guys, but as Darren points > out, it's a drag to have to be a single point of failure on something > like this where corroboration would be better. You can trust and verify :) ssh-keygen -T /tmp/moduli < /etc/moduli Will run the Miller-Rabin tests on your own system, and with open-source code. > In that spirit, i've just tested the moduli (both the 2012 versions and > the recent update), using gmp's mpz_probab_prime_p() [2] with 400 rounds > of randomized Miller-Rabin [3] on each modulus p and on q=(p-1)/2. That works too :) -d From djm at mindrot.org Mon May 25 09:46:01 2015 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 May 2015 09:46:01 +1000 (AEST) Subject: [PATCH] sshd: make "-c" option usable In-Reply-To: References: Message-ID: On Sun, 24 May 2015, Darren Tucker wrote: > On Sun, May 24, 2015 at 7:16 PM, Felix Bolte wrote: > > > please see my pull request on github > > (patch attached as well to this mail): > > > > > https://github.com/openssh/openssh-portable/pull/21 > > > > Thanks! > > Looks like it's missing in OpenBSD too, so we need to apply it there > first. Damien? > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.372&r2=1.373&f=h Yep, applied - thanks! -d From djm at mindrot.org Mon May 25 09:51:41 2015 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 May 2015 09:51:41 +1000 (AEST) Subject: Name based SSH proxy In-Reply-To: <20150523124206.GA3538@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> Message-ID: On Sat, 23 May 2015, Kasper Dupont wrote: > I am working on a proxy which can be hosted on a single > IP address and dispatch requests to different backends > depending on which hostname the client used to connect to > this IP address. > > Currently such a proxy can be build to support HTTP, HTTPS, > SMTP, and DNS. However SSH support is impossible due to > the ssh client not sending the information such a proxy > would need. > > I am not the first to want such a proxy: > http://serverfault.com/q/34552/214507 > However my searches only found people talking about it, > and nobody doing anything about it. > > I have attached a tiny patch for the openssh-client, which > I believe does everything openssh would need to do in order > to support this kind of proxies. > > What are your thoughts on the attached patch? I'm not sure it should be part of the banner exchange, though there is no other trivial way to do it and maintain backwards compatibility. I don't much like it because it reveals host identity information in the clear. A better way would be to exchange this after the connection has been keyed, but that would require extensive changes to the key exchange protocol. I don't really want to implement a half-measure in OpenSSH... -d From kasperd at kdxdx.23.may.2015.kasperd.net Mon May 25 17:39:27 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Mon, 25 May 2015 09:39:27 +0200 Subject: Name based SSH proxy In-Reply-To: References: <20150523124206.GA3538@colin.search.kasperd.net> Message-ID: <20150525073927.GA3492@colin.search.kasperd.net> On 25/05/15 09.51, Damien Miller wrote: > I'm not sure it should be part of the banner exchange, though there is > no other trivial way to do it and maintain backwards compatibility. Even if backwards compatibility wasn't a requirement, I don't see any better way it could be done. > I don't much like it because it reveals host identity information > in the clear. So does the DNS lookup performed before the TCP connection is being established. So that can hardly be considered a secret. > > A better way would be to exchange this after the connection has > been keyed, but that would require extensive changes to the key > exchange protocol. How would that work? The proxy doesn't hold the server key. The proxy doesn't even know which server holds the key. > > I don't really want to implement a half-measure in OpenSSH... All the proxy needs to know is the hostname which was previously send in clear to multiple DNS servers. And the only concern you have brought up is that you don't want this to be send in clear. I need a little bit of help to understand what your concern is here. I'll try to explain my usage scenario in a bit more detail. I have a number of servers each running IPv6 only. Since some clients will only have access to IPv4, I have deployed a proxy on a dual stack host. But the proxy only has a single IPv4 address. Clients connect to this address, and the proxy performs a DNS lookup to find the IPv6 address which this client wants to connect to. Currently this works for HTTP, HTTPS, SMTP, and DNS. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dtucker at zip.com.au Mon May 25 21:16:54 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 25 May 2015 21:16:54 +1000 Subject: Name based SSH proxy In-Reply-To: <20150525073927.GA3492@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> Message-ID: On Mon, May 25, 2015 at 5:39 PM, Kasper Dupont < kasperd at kdxdx.23.may.2015.kasperd.net> wrote: [...] > I'll try to explain my usage scenario in a bit more detail. > I have a number of servers each running IPv6 only. Since > some clients will only have access to IPv4, I have deployed > a proxy on a dual stack host. But the proxy only has a > single IPv4 address. Assuming you have sufficient CPU and an account on the dual stack host (but it could be a single restricted one), we already have a pretty functional SSH proxy: ssh "netcat mode". It takes a little bit of client side configuration, but basically it looks like this in ~/.ssh/config Host v6host1 v6host2 v6host3 ProxyCommand ssh -W %h:%p dualstackhost -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kasperd at kdxdx.23.may.2015.kasperd.net Mon May 25 22:51:54 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Mon, 25 May 2015 14:51:54 +0200 Subject: Name based SSH proxy In-Reply-To: References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> Message-ID: <20150525125154.GA3507@colin.search.kasperd.net> On 25/05/15 21.16, Darren Tucker wrote: > On Mon, May 25, 2015 at 5:39 PM, Kasper Dupont < > kasperd at kdxdx.23.may.2015.kasperd.net> wrote: > [...] > > > I'll try to explain my usage scenario in a bit more detail. > > I have a number of servers each running IPv6 only. Since > > some clients will only have access to IPv4, I have deployed > > a proxy on a dual stack host. But the proxy only has a > > single IPv4 address. > > > Assuming you have sufficient CPU and an account on the dual stack host (but > it could be a single restricted one), we already have a pretty functional > SSH proxy: ssh "netcat mode". I don't know if CPU usage is going to be an issue for me. Given an approach where CPU usage was the only known issue, I would surely give it a try. > > It takes a little bit of client side configuration, but basically it looks > like this in ~/.ssh/config > > Host v6host1 v6host2 v6host3 > ProxyCommand ssh -W %h:%p dualstackhost I know of this approach and occasionally use it in other scenarios, but I don't think it could address all of the needs my proxy would have. First of all, the proxy is only supposed to be used as fallback when the client does not have IPv6 connectivity. The client might move between different networks, and when it is on a network with IPv6 connectivity, I want it to connect directly to the target. The ProxyCommand approach works great when there is a desire to not put the target host directly on a publicly reachable IP address for security reasons. That is however not the scenario I am trying to address. The scenario I am trying to address is when the only reason for not having the target on a public address is shortage of IPv4 addresses. A ProxyCommand which attempts direct IPv6 connectivity and then falls back to a proxy if direct access didn't work is surely an option. There is however a few other concerns which apply to my specific usage scenario. The proxy I am operating will be publicly accessible, and due to that I have a few additional requirements: 1. The proxy have to guarantee that the hostname being used will be easily visible to the administrator of the server which the backend eventually connects to. 2. The proxy doesn't trust the users. Hence the users don't have an SSH login on the proxy. 3. The users don't trust the proxy anymore than they would trust a random router which the SSH connection got routed through. Point 3 might not really be a problem. Having the users store a host key for the proxy doesn't itself pose any problems. Point 2 I could probably work around with sufficient sandboxing. But point 1 on my list appears seems to be a bit of a blocker. Any approach used by the proxy to embed the hostname into the TCP connection would mean a change of data that is subject to integrity check between client and server. So I am at loss as to how the proxy could communicate the hostname to the server. Also. There is nothing in the requirements for my usage scenario, which would benefit from the communication between client and proxy to be embedded in another layer of SSH. And since it would require configuration changes on the client anyway, I would most likely replace that part with something with less overhead such as possibly using an HTTP proxy supporting a restricted version of the CONNECT command. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From jjelen at redhat.com Mon May 25 23:32:51 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 25 May 2015 15:32:51 +0200 Subject: ssh closing file descriptors for ControlPersist Message-ID: <55632483.7080001@redhat.com> Hi all, we were discussing internally how to make openssh leave open file descriptors that were open before main using LD_PRELOAD. Lately I filled upstream bugzilla [1] with proposed solution, that could be acceptable by upstream, but I'm also posting on this list to get more attention, other points of view or ideas for this case. I understand well, that closing FDs is important for backgrounded [mux] process who is handling IO for all sessions in specific connection. I also understand, that it is good practice to know what are your open file descriptors and close the other "hanging around". But aside all of this, what would be proposal if you would need to preserve this open file descriptor? In above mentioned bugzilla, I'm proposing to close these FDs only if we have configuration option ControlPersist enabled (as comments in code describes). This requires to move the the whole closing thing down after reading config files and commandline options. But this can interfere with debug logging enabled (using -E option), so to make it working, it is required to reopen this log file after closing other FDs. Q: File descriptor from debug log (-E option) doesn't matter when backgrounding ControlPersist master? Q: For non-backgrounding process using ControlMaster only is not a problem to have hanging file descriptors around? I'm interested only in preserving this FD without multiplexing, but of course I want to have multiplexing working after this change. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2394 -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From djm at mindrot.org Tue May 26 09:44:36 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 26 May 2015 09:44:36 +1000 (AEST) Subject: ssh closing file descriptors for ControlPersist In-Reply-To: <55632483.7080001@redhat.com> References: <55632483.7080001@redhat.com> Message-ID: On Mon, 25 May 2015, Jakub Jelen wrote: > Hi all, > we were discussing internally how to make openssh leave open file descriptors > that were open before main using LD_PRELOAD. Something running in ssh's address space could do just about anything. If we start making changes for random stuff that users force in via LD_PRELOAD, where would we stop? -d From peter at stuge.se Tue May 26 09:50:05 2015 From: peter at stuge.se (Peter Stuge) Date: Tue, 26 May 2015 01:50:05 +0200 Subject: Name based SSH proxy In-Reply-To: <20150523124206.GA3538@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> Message-ID: <20150525235005.13809.qmail@stuge.se> Kasper Dupont wrote: > +send_client_banner(int connection_out, int minor1, const char *host) > { > /* Send our own protocol version identification. */ > if (compat20) { > - xasprintf(&client_version_string, "SSH-%d.%d-%.100s\r\n", > - PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION); > + xasprintf(&client_version_string, > + "SSH-%d.%d-%.100s {\"SNI\": \"%.133s\"}\r\n", > + PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION, host); You propose introducing JSON injection. Really? Aside from all the other valid criticism, JSON is a bad fit. //Peter From jjelen at redhat.com Tue May 26 18:15:43 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 26 May 2015 10:15:43 +0200 Subject: ssh closing file descriptors for ControlPersist In-Reply-To: References: <55632483.7080001@redhat.com> Message-ID: <55642BAF.2040508@redhat.com> On 05/26/2015 01:44 AM, Damien Miller wrote: > On Mon, 25 May 2015, Jakub Jelen wrote: > >> Hi all, >> we were discussing internally how to make openssh leave open file descriptors >> that were open before main using LD_PRELOAD. > Something running in ssh's address space could do just about anything. > > If we start making changes for random stuff that users force in > via LD_PRELOAD, where would we stop? > > -d Thanks for your reply. I totally accept your attitude from developer point of view. I wanted to gather some opinions from other people around openssh about this issue not to have it only as an internal discussion which just started to lead nowhere. Unfortunately, the world is not ideal place and some people are using strange constructions. And sometimes we need to make compromises. Jakub From peter at stuge.se Tue May 26 19:18:41 2015 From: peter at stuge.se (Peter Stuge) Date: Tue, 26 May 2015 11:18:41 +0200 Subject: ssh closing file descriptors for ControlPersist In-Reply-To: <55642BAF.2040508@redhat.com> References: <55632483.7080001@redhat.com> <55642BAF.2040508@redhat.com> Message-ID: <20150526091841.22160.qmail@stuge.se> Jakub Jelen wrote: >> If we start making changes for random stuff that users force in >> via LD_PRELOAD, where would we stop? > > I wanted to gather some opinions from other people around openssh I can only support the developer opinion. > sometimes we need to make compromises. That's a problem for Red Hat to solve on its own. Don't try to push your problems onto upstream projects, thank you very much. //Peter From igor at mir2.org Wed May 27 02:55:42 2015 From: igor at mir2.org (Igor Bukanov) Date: Tue, 26 May 2015 18:55:42 +0200 Subject: sandox or non-root for single user Message-ID: Hi, If I need to provide an ssh access just for a single user and I want to minimize a chance of malicious code running as root even if it increases a possibility for malicious code running as that user. Given that should I try running sshd as that user? Or should I continue to use UsePrivilegeSeparation=sandbox with sshd running as root? thanks, Igor Bukanov From hkario at redhat.com Wed May 27 02:57:05 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 26 May 2015 18:57:05 +0200 Subject: Weak DH primes and openssh In-Reply-To: <87r3q8nz0q.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <87r3q8nz0q.fsf@alice.fifthhorseman.net> Message-ID: <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> On Friday 22 May 2015 16:22:13 Daniel Kahn Gillmor wrote: > On Fri 2015-05-22 00:06:29 -0400, Darren Tucker wrote: > > On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon wrote: > >> You will be aware of https://weakdh.org/ by now, I presume; the > >> take-home seems to be that 1024-bit DH primes might well be too weak. > >> I'm wondering what (if anything!) you propose to do about this issue, > >> and what Debian might do for our users? > > > > Would you (and any other vendors) consider generating your own moduli file > > for your distribution? If a few vendors did that it'd increase the > > diversity quite a lot and it'd stop us (well, specifically me) being the > > point of failure for not making updates. > > (thanks for making the recent moduli update, Darren!) > > This is an interesting proposal as a way to increase group diversity, > but it also creates a non-obvious fingerprinting channel. That is, > distro-specific groups would provide a way that someone scanning to find > out what distro is in use can make a more accurate guess based on the > primes offered. > > I grant that debian's current patches that add the debian revision > themselves provide a fingerprinting mechanism, but those can be disabled > on Debian with "DebianBanner no" in sshd_config. We'd want to make sure > that distro-specific moduli don't re-introduce fingerprinting for > operators who want to hide their choice of distro. > > --dkg > > PS Darren, has there been any attempt at generating primality proofs for > the values in ./moduli, as opposed to 100 rounds of Miller-Rabin? It > would be a shame for a pseudoprime to slip in, however unlikely that > would be. creating composites that will pass even 100000 rounds of Miller-Rabin is relatively simple.... (assuming the values for M-R tests are picked randomly) I'd be against shipping any primes that are not generated from known, expected values, like hash of "OpenSSH 1024 bit DH prime, try #1" -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Wed May 27 03:43:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 May 2015 13:43:13 -0400 Subject: Weak DH primes and openssh In-Reply-To: <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> References: <555DDD09.3090606@debian.org> <87r3q8nz0q.fsf@alice.fifthhorseman.net> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> Message-ID: <87lhgbkzf2.fsf@alice.fifthhorseman.net> On Tue 2015-05-26 12:57:05 -0400, Hubert Kario wrote: > creating composites that will pass even 100000 rounds of Miller-Rabin is > relatively simple.... > (assuming the values for M-R tests are picked randomly) Can you point me to the algorithms for doing that? This would suggest that we really do want primality proofs (and a good way to verify them). Do those algorithms hold for creating composites that pass M-R tests for both p and (p-1)/2 ? > I'd be against shipping any primes that are not generated from known, expected > values, like hash of "OpenSSH 1024 bit DH prime, try #1" This is trying to put some sort of NUMS-y ("Nothing Up My Sleeve") constraint on prime generation -- presumably you'd count up from the hash value until you find something that passes M-R for both p and (p-1)/2, right? I observe that the values in ./moduli all seem quite similar in that respect (i.e. the values for any given length share most of the same prefix, and differ only in the trailing bits). Wouldn't primality proofs make this NUMS-y approach less relevant? --dkg From hkario at redhat.com Wed May 27 04:02:07 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 26 May 2015 20:02:07 +0200 Subject: Weak DH primes and openssh In-Reply-To: <87lhgbkzf2.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> Message-ID: <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> On Tuesday 26 May 2015 13:43:13 Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 12:57:05 -0400, Hubert Kario wrote: > > creating composites that will pass even 100000 rounds of Miller-Rabin is > > relatively simple.... > > (assuming the values for M-R tests are picked randomly) > > Can you point me to the algorithms for doing that? OEIS A014233 > This would suggest > that we really do want primality proofs (and a good way to verify them). yes, using ECPP and distributing proof with the prime (or just placing it on the project website) is a reasonable minimum, that still leaves out the possibility of a backdoor if the initial seed value is random > Do those algorithms hold for creating composites that pass M-R tests for > both p and (p-1)/2 ? that I don't know, I'd assume it's much harder, that being said, the A014233 is suspiciously short... > > I'd be against shipping any primes that are not generated from known, > > expected values, like hash of "OpenSSH 1024 bit DH prime, try #1" > > This is trying to put some sort of NUMS-y ("Nothing Up My Sleeve") > constraint on prime generation yes > -- presumably you'd count up from the > hash value until you find something that passes M-R for both p and > (p-1)/2, right? yes, use it as the base for the PRNG to get candidates > I observe that the values in ./moduli all seem quite > similar in that respect (i.e. the values for any given length share most > of the same prefix, and differ only in the trailing bits). > > Wouldn't primality proofs make this NUMS-y approach less relevant? yes, it would basically exclude the chance that the primes are backdoored, there's still the chance for the values to be composites for values to be used on this many machines, I'd say we should have primality proofs, not just M-R "guess" -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Wed May 27 05:10:01 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 May 2015 15:10:01 -0400 Subject: Weak DH primes and openssh In-Reply-To: <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> Message-ID: <87y4kbjgty.fsf@alice.fifthhorseman.net> On Tue 2015-05-26 14:02:07 -0400, Hubert Kario wrote: > On Tuesday 26 May 2015 13:43:13 Daniel Kahn Gillmor wrote: >> On Tue 2015-05-26 12:57:05 -0400, Hubert Kario wrote: >> > creating composites that will pass even 100000 rounds of Miller-Rabin is >> > relatively simple.... >> > (assuming the values for M-R tests are picked randomly) >> >> Can you point me to the algorithms for doing that? > > OEIS A014233 Hm, this is a sequence, but not an algorithm. It looks to me like it is not exhaustive, just a list of those integers which are known to have the stated property ("Smallest odd number for which Miller-Rabin primality test on bases <= n-th prime does not reveal compositeness"). Taking the final integer in that sequence (a(11)) fails even the default 25-round M-R test in gmp: >>> k = gmpy2.mpz(3825123056546413051) >>> gmpy2.is_prime(k) False >>> Indeed, the arxiv suggests that in 2012 people were still writing proofs about a(11) for this sequence: http://arxiv.org/abs/1207.0063 but i see no evidence that an algorithm for generating a(n) where n is arbitrarily large exists. Does such a thing exist? > yes, using ECPP and distributing proof with the prime (or just placing it on > the project website) is a reasonable minimum, that still leaves out the > possibility of a backdoor if the initial seed value is random it sounds like we're heading into the same territory as the ECDH curve selection discussion -- the theory you're suggesting is that some safe-prime moduli could themselves have a backdoor that we don't know about. Am i understanding you correctly? I've been talking with several cryptographers for the last year about finite-field DH (FFDH) and i haven't heard any suggestion that any of them think there is likely to be such a class of backdoored moduli. > yes, it would basically exclude the chance that the primes are backdoored, > there's still the chance for the values to be composites > > for values to be used on this many machines, I'd say we should have primality > proofs, not just M-R "guess" Does anyone have a pointer to any decent free software for generating and verifying primality proofs? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From mdb at juniper.net Wed May 27 05:39:49 2015 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 26 May 2015 12:39:49 -0700 Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group In-Reply-To: References: Message-ID: <48704.1432669189@eng-mail01.juniper.net> Hi Folks, The generator value of 5 does not lead to a q-ordered subgroup which is needed to pass tests in http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf 1. Verify that 2 <= y <= p-2 2. Verify that y^q = 1 (mod p) It appears that choosing a generator values of 2, 3, 7, 11, or 13 would all work as generator values. I do understand that RFC 4419 wants you to chose a g = 2 value only when p (mod 24) == 11, but that is not always a good selection. With the p value given, and q created with (p-1)/2, running BN_is_prime_fasttest(p, 0, NULL, ctx, NULL, 0) shows p is prime q = BN_dup(dhg.p) BN_sub_word(q, 1) BN_rshift1(q, q) BN_is_prime_fasttest(q, 0, NULL, ctx, NULL, 0) shows q is prime BN_mod_word(p, 24) == 23 BN_mod_word(p, 10) == 3 # RFC 4419 says g == 5 when p (mod 10) = 3 BN_mod_word(p, 12) == 11 If I use the values below, then NIST SP 800-56A Revision 1 of March 2007 tests work on all values of y that I tested. If I use a generator g = 5, then I was getting failures. static char *gen = "2"; static char *p = "DDE41D70" "21F9DF82" "40D0BD8E" "14CE1E37" "4A4FFDD0" "73767E84" "C8C347B6" "F8327312" "77F9D333" "B8BC7CD9" "6ED164DF" "5C6F26E4" "6E4BAF0A" "A7C87B26" "CE3E1104" "2C1BDDF7" "6095E50D" "7772E5DC" "0C48EBA0" "E41EC92E" "AFA655DA" "1B6C614E" "1F0F9AD8" "15BD7505" "AA9B8A26" "5D13956B" "5A26141E" "E812404D" "E13B821C" "9B7BCA99" "82B8CF7D" "862F8E8A" "373FEFEE" "4AE46EC2" "122519A2" "AD896ED1" "8CAECEF3" "14D1B98C" "83358B6E" "9D2F3BC5" "8C1688F1" "62E3CF1F" "F58E57E7" "B9E14BB3" "7C9C9E96" "92E57C42" "937141C2" "26E84C35" "B42DED90" "55A7F366" "A61C3CB4" "899B4992" "78ED4C72" "9CC1DE54" "827E8822" "90F9FC13" "F7F1488F" "897698EA" "62A99468" "D6F3ED05" "61816C39" "B8279154" "FC7A8E45" "3CCC4EB1" "ABC777A3" "97B694E1" "B9866C24" "95489F94" "721A3351" "B252D05F" "E6C78579" "29B34C19" "A8EB42AB" "ED88FA37" "0DABCA83" "A245DC35" "CFB39982" "4D127507" "AD540054" "C647F61C" "6BD11CAF" "C3FE5277" "A1014DF6" "B538BC8B" "FE009315" "BCD60E02" "0DAB840B" "8A4219EB" "A4E34968" "0BC7CA3A" "9BC36164" "A3D36E32" "5C530B17" "8747814F" "57589912" "6B307EB6" "3F910DDE" "0F09E505" "6B2F9F7E" "230A42C1" "1DDD34A9" "B23A6409" "0C2FF9C7" "F3DD696E" "6828613E" "74A64CFC" "4046ECFA" "997BE849" "81430D8A" "7F8AEC63" "001E50AF" "9F556567" "A0065A9A" "013A66A2" "737CEEE4" "68D6A150" "02358AC6" "48D862B0" "618E6DD6" "A98BBBE9" "E68174D9" "C9FE4568" "BB2D1208" "3CF6892B" "6B8D5830" "7944955A" "987F3791" "775049BF"; There is probaby a better way to calculate the generator g value using FCC math, but I am pretty sure that the values you are putting into https://bugzilla.mindrot.org/attachment.cgi?id=2630 are not going to be useful if anyone needs to pass NIT SP 800-56A with those values. Thanks for your time! -- Mark From dkg at fifthhorseman.net Wed May 27 05:50:26 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 May 2015 15:50:26 -0400 Subject: Name based SSH proxy In-Reply-To: <20150525073927.GA3492@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> Message-ID: <87pp5njeyl.fsf@alice.fifthhorseman.net> On Mon 2015-05-25 03:39:27 -0400, Kasper Dupont wrote: > On 25/05/15 09.51, Damien Miller wrote: >> I don't much like it because it reveals host identity information >> in the clear. > > So does the DNS lookup performed before the TCP connection > is being established. So that can hardly be considered a > secret. I hope we do not introduce a cleartext SNI into the SSH protocol. This leaks far too much sensitive metadata for passive monitors. TLS has cleartext SNI, and it is quite difficult to figure out how to protect it from passive monitors (and i think impossible to protect from active attackers who are willing to cause connection failures to learn the client's intended SNI). We should not add this additional layer of metadata leakage to SSH as well. The argument that the DNS lookup leaks this metadata is a bad argument: if we followed this line of reasoning, then every problem that has multiple contributors could never be solved (A says "but my fixing things is useless if B does nothing", while B says "but my fixing things is useless if A does nothing" -- a classic collective action problem). In practice, there is work done today to protect DNS queries as well (see the DNS Privacy working group in the IETF, the latest versions of libunbound and the getdns API, etc). Let's not introduce a new layer of the same problem. I think the ProxyCommand Kasper ended up describing (checking for v6 connectivity or using a constrained HTTP CONNECT proxy) is a acceptable way to go for people in the particular scenario he's concerned about. Changing everyone else's SSH connections to leak that metadata for the sake of this corner case would be a bad tradeoff. Regards, --dkg From kasperd at kdxdx.23.may.2015.kasperd.net Wed May 27 07:42:40 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Tue, 26 May 2015 23:42:40 +0200 Subject: Name based SSH proxy In-Reply-To: <87pp5njeyl.fsf@alice.fifthhorseman.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> Message-ID: <20150526214240.GA3469@colin.search.kasperd.net> On 26/05/15 15.50, Daniel Kahn Gillmor wrote: > The argument that the DNS lookup leaks this metadata is a bad argument: > if we followed this line of reasoning, then every problem that has > multiple contributors could never be solved (A says "but my fixing > things is useless if B does nothing", while B says "but my fixing things > is useless if A does nothing" -- a classic collective action problem). That sort of excuse certainly exists out there. In fact that's the only reason anybody is still using IPv4. If people had put just a little bit more effort into long term solutions, we would all have been running IPv6 years ago. And in that case, we wouldn't be having this discussion, because there would be enough IP addresses that SNI would never have been invented. This leads me to my next question. Would it be sensible to modify my patch to make it configurable with three options for when to send the hostname? The three options I would have in mind are: always, only on IPv4, and never. > > In practice, there is work done today to protect DNS queries as well > (see the DNS Privacy working group in the IETF, the latest versions of > libunbound and the getdns API, etc). I haven't seen any of the work done in those areas. But considering how little traction DNSSEC has, I would imagine that DNS privacy initiatives would take decades to get any traction. If you have any pointers, I am very curious as to exactly how they intend to do get any privacy into the DNS protocol. > > I think the ProxyCommand Kasper ended up describing (checking for v6 > connectivity or using a constrained HTTP CONNECT proxy) is a acceptable > way to go for people in the particular scenario he's concerned about. But it does not address all my requirements. I have a requirement that the hostname being used must be visible to the administrator of the SSH server. And it must be visible with minimal effort without requiring any software changes on the server. Sending the hostname in clear from proxy to server would address that concern. But there are not many opportunities for a proxy to inject data into the data stream from client to server without breaking integrity checks on the packets. Assuming I could find a way to embed that information inside the stream from proxy to server, then there is nothing stopping me from embeding the information inside the connection from client to proxy as well. And it would certainly be desirable for me if the proxy did not have to modify the data in transit at all. So if I could write a ProxyCommand which would embed the hostname into the stream from client to proxy, then the proxy could simply pick out the hostname and pass the traffic unmodified to the server. I carefully read the relevant RFCs in order to figure out which information is covered by integrity checks and which is not. I found a method which would work according to the RFC, but it turns out OpenSSH doesn't behave as specified by the RFC. One thing I found was RFC 4253 saying: An implementation MUST respond to all unrecognized messages with an SSH_MSG_UNIMPLEMENTED message in the order in which the messages were received. Such messages MUST be otherwise ignored. Later protocol versions may define other meanings for these message types. However what I found OpenSSH to be doing was for every unrecognized message it would either ignore it and not send an SSH_MSG_UNIMPLEMENTED, or send an error and disconnect. Is it deliberate that OpenSSH doesn't do what RFC 4253 says MUST be done? I am still pondering on whether there are other ways to get the hostname communicated across to the server without breaking the integrity of the connection. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dkg at fifthhorseman.net Wed May 27 08:29:00 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 May 2015 18:29:00 -0400 Subject: Name based SSH proxy In-Reply-To: <20150526214240.GA3469@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> Message-ID: <87h9qzj7mb.fsf@alice.fifthhorseman.net> On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: > And in that case, we wouldn't be having this discussion, > because there would be enough IP addresses that SNI would > never have been invented. unless people wanted to co-tenant anyway, which is conceivable for other reasons like minimizing inference that can be drawn from metadata. In these metadata-sensitive co-tenanted arrangements, we'd want protected SNI, not cleartext. > I haven't seen any of the work done in those areas. But > considering how little traction DNSSEC has, I would > imagine that DNS privacy initiatives would take decades > to get any traction. > > If you have any pointers, I am very curious as to exactly > how they intend to do get any privacy into the DNS > protocol. https://datatracker.ietf.org/wg/dprive/documents/ the goal is to start with protection of the stub-to-recursive link, and think about protecting the recursive-to-authoritative link later. https://datatracker.ietf.org/doc/draft-ietf-dprive-start-tls-for-dns/ is the most promising one at the moment. This is completely orthogonal to DNSSEC, and the folks working on it are well aware of the failings there. >> I think the ProxyCommand Kasper ended up describing (checking for v6 >> connectivity or using a constrained HTTP CONNECT proxy) is a acceptable >> way to go for people in the particular scenario he's concerned about. > > But it does not address all my requirements. I have a > requirement that the hostname being used must be visible > to the administrator of the SSH server. And it must be > visible with minimal effort without requiring any software > changes on the server. The patch you're sending is a software change :) > But there are not many opportunities for a proxy to inject > data into the data stream from client to server without > breaking integrity checks on the packets. no, the proxycommand has to wrap the ssh traffic in an outer-layer tunnel. > One thing I found was RFC 4253 saying: > > An implementation MUST respond to all unrecognized messages with an > SSH_MSG_UNIMPLEMENTED message in the order in which the messages were > received. Such messages MUST be otherwise ignored. Later protocol > versions may define other meanings for these message types. > > However what I found OpenSSH to be doing was for every > unrecognized message it would either ignore it and not > send an SSH_MSG_UNIMPLEMENTED, or send an error and > disconnect. > > Is it deliberate that OpenSSH doesn't do what RFC 4253 > says MUST be done? This is a separate question, which i haven't done enough reading or testing to answer. hopefully Damien or Darren can comment on it. > I am still pondering on whether there are other ways to > get the hostname communicated across to the server without > breaking the integrity of the connection. If you're going to prevent passive attackers from sniffing it, it would have to be done after the key exchange, which would suggest that the proxy would need to know the secret key material for the session. That seems like a bad outcome either way. --dkg From keisial at gmail.com Wed May 27 09:11:34 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 27 May 2015 01:11:34 +0200 Subject: Name based SSH proxy In-Reply-To: <20150525125154.GA3507@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <20150525125154.GA3507@colin.search.kasperd.net> Message-ID: <5564FDA6.7040107@gmail.com> On 25/05/15 14:51, Kasper Dupont wrote: > The proxy I am operating will be publicly accessible, and > due to that I have a few additional requirements: > > 1. The proxy have to guarantee that the hostname being > used will be easily visible to the administrator of > the server which the backend eventually connects to. > 2. The proxy doesn't trust the users. Hence the users > don't have an SSH login on the proxy. > 3. The users don't trust the proxy anymore than they would > trust a random router which the SSH connection got > routed through. > > Point 3 might not really be a problem. Having the users > store a host key for the proxy doesn't itself pose any > problems. Point 2 I could probably work around with > sufficient sandboxing. > > But point 1 on my list appears seems to be a bit of a > blocker. Any approach used by the proxy to embed the > hostname into the TCP connection would mean a change of > data that is subject to integrity check between client > and server. So I am at loss as to how the proxy could > communicate the hostname to the server. I think you can achieve all of this with no changes to ssh(d) software (but a bit of trickery). Then ~/.ssh/config would contain Host v6host1 v6host2 v6host3 ProxyCommand ssh -W %h:%p -p %p -o UserKnownHostsFile=~/.ssh/known_hosts,~/.ssh/known_proxy %h.example.com (note that simply a %h in the ProxyCommand would lead to a loop) and set in vhostN dns both its IPv6 and dualstackhost IP address. You add in the normal ~/.ssh/known_hosts the normal entry for v6hostX with its real key, and in ~/.ssh/known_proxy another entry for v6hostX with the public key for dualstackhost. If there's IPv6 connectivity, you connect directly to the final machine, with a redundant tunneling through localhost. With no IPv6 connectivity, the IPv4 address is used, so you connect to the proxy. As there is an alias for the proxy public key is listed inside known_proxy, the tunneling connection is allowed. However, the outer ssh invocation is not loading known_proxy and won't accept such key (thus the proxy can't impersonate the hosts). Your users require a login into the proxy server, but not necessarily the ability to run processes, just the ability of performing port forwardings (you can restrict with permitopen= the list of hosts to which they are allowed to open a connection). For your specific use case, you may wish to use a well-known user in the ProxyCommand (ie. all users connect to the proxy with the same login with a published secret key). > Also. There is nothing in the requirements for my usage > scenario, which would benefit from the communication > between client and proxy to be embedded in another layer > of SSH. And since it would require configuration changes > on the client anyway, I would most likely replace that > part with something with less overhead such as possibly > using an HTTP proxy supporting a restricted version of the > CONNECT command. Sure. There's no special need for protecting the communication between the client and the proxy in your case. You could perfectly use a custom ProxyCommand that tunnels through HTTP CONNECT if there's no IPv6 connectivity. From kasperd at kdxdx.23.may.2015.kasperd.net Wed May 27 09:22:34 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 01:22:34 +0200 Subject: Name based SSH proxy In-Reply-To: <87h9qzj7mb.fsf@alice.fifthhorseman.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <87h9qzj7mb.fsf@alice.fifthhorseman.net> Message-ID: <20150526232234.GA3493@colin.search.kasperd.net> On 26/05/15 18.29, Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: > > But it does not address all my requirements. I have a > > requirement that the hostname being used must be visible > > to the administrator of the SSH server. And it must be > > visible with minimal effort without requiring any software > > changes on the server. > > The patch you're sending is a software change :) My requirements only said no software changes on the server. It was clear to me very early on, that some changes were needed on the client side. Whether the client side changes can be done as a ProxyCommand remains an open question. But it is certain that a modification of the ssh client would cover all my needs. > > > > But there are not many opportunities for a proxy to inject > > data into the data stream from client to server without > > breaking integrity checks on the packets. > > no, the proxycommand has to wrap the ssh traffic in an outer-layer > tunnel. I need the proxy to communicate with an unmodified server. And I need this communication to include the hostname for the administrator of said server to see. Whether the administrator would have to look in a logfile or a packet capture in order to see the hostname is not important. I believe that once I have an answer to how the proxy can communicate the hostname to the server, then everything else will follow. > > I am still pondering on whether there are other ways to > > get the hostname communicated across to the server without > > breaking the integrity of the connection. > > If you're going to prevent passive attackers from sniffing it, it would > have to be done after the key exchange, which would suggest that the > proxy would need to know the secret key material for the session. That > seems like a bad outcome either way. None of my requirements say the hostname must remain hidden from a passive attacker. So for me it only makes sense to first look for a solution which satisfy my requirements, and only once the requirements are satisfied look for ways to improve the solution to have other nice properties. Sending the hostname after key exchange is impossible. The proxy need to know which server to communicate with, that's the point of sending the hostname in the first place. That means key exchange can only start after the hostname has been sent to the proxy. I don't yet know a way to acheive my desired result using just a ProxyCommand. But with the following change and a ProxyCommand, I believe I would be able to achieve what I am looking for. diff -up openssh-6.6p1/sshconnect.c.original openssh-6.6p1/sshconnect.c --- openssh-6.6p1/sshconnect.c.original 2015-05-23 11:56:55.235217137 +0200 +++ openssh-6.6p1/sshconnect.c 2015-05-27 01:14:02.563652677 +0200 @@ -560,6 +560,9 @@ ssh_exchange_identification(int timeout_ if (options.protocol == SSH_PROTO_2) { enable_compat20(); send_client_banner(connection_out, 0); + packet_send_ignore(0); + packet_send(); + packet_write_wait(); client_banner_sent = 1; } The question then is, would the security implications of adding these three lines be much worse than my original patch? -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From keisial at gmail.com Wed May 27 09:42:55 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 27 May 2015 01:42:55 +0200 Subject: Name based SSH proxy In-Reply-To: <20150526214240.GA3469@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> Message-ID: <556504FF.6020105@gmail.com> On 26/05/15 23:42, Kasper Dupont wrote: >> > I think the ProxyCommand Kasper ended up describing (checking for v6 >> > connectivity or using a constrained HTTP CONNECT proxy) is a acceptable >> > way to go for people in the particular scenario he's concerned about. > But it does not address all my requirements. I have a > requirement that the hostname being used must be visible > to the administrator of the SSH server. And it must be > visible with minimal effort without requiring any software > changes on the server. > > Sending the hostname in clear from proxy to server would > address that concern. > > But there are not many opportunities for a proxy to inject > data into the data stream from client to server without > breaking integrity checks on the packets. Why do you want the hostname being used to "be visible to the administrator of the SSH server"? I assumed you wanted to send the final hostname to the *proxying SSH server*. In which case, you don't need such thing if using a HTTP CONNECT proxy (the hostname is now given to the HTTP proxy). And if you use a ssh server like the ssh tunneling I proposed, the final hostname is already provided, too. If you want instead to give the hostname used to the *final* sshd, that's a different requirement for which you provided no rationale (and I suspect you are not really interested in). Much more interesting at the final end than the requested would be to have the original client IP (ie. X-Forwarded-For) but that would open a different can of worms (and required software changes) about proxies whose forwarded IPs should be trusted. Something I would prefer not to enter into. A similar idea I had thought in the past was the ability to transparently forward a connection after authentication to a different machine (after the PrivSep step, the new sshd would be in a different host in the LAN). It differs from Kasper proxy in that the proxy would be trusted (seen as the real machine from the outside). From keisial at gmail.com Wed May 27 09:53:10 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 27 May 2015 01:53:10 +0200 Subject: ssh closing file descriptors for ControlPersist In-Reply-To: <55632483.7080001@redhat.com> References: <55632483.7080001@redhat.com> Message-ID: <55650766.10307@gmail.com> On 25/05/15 15:32, Jakub Jelen wrote: > I understand well, that closing FDs is important for backgrounded > [mux] process who is handling IO for all sessions in specific > connection. I also understand, that it is good practice to know what > are your open file descriptors and close the other "hanging around". > But aside all of this, what would be proposal if you would need to > preserve this open file descriptor? Why would you need this open file descriptor? From keisial at gmail.com Wed May 27 10:04:27 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 27 May 2015 02:04:27 +0200 Subject: Name based SSH proxy In-Reply-To: <20150526232234.GA3493@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <87h9qzj7mb.fsf@alice.fifthhorseman.net> <20150526232234.GA3493@colin.search.kasperd.net> Message-ID: <55650A0B.1040107@gmail.com> On 27/05/15 01:22, Kasper Dupont wrote: > On 26/05/15 18.29, Daniel Kahn Gillmor wrote: >> On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: >>> But it does not address all my requirements. I have a >>> requirement that the hostname being used must be visible >>> to the administrator of the SSH server. And it must be >>> visible with minimal effort without requiring any software >>> changes on the server. >> The patch you're sending is a software change :) > My requirements only said no software changes on the server. > It was clear to me very early on, that some changes were > needed on the client side. > > Whether the client side changes can be done as a > ProxyCommand remains an open question. But it is certain > that a modification of the ssh client would cover all my > needs. ...with a modified server that acts as a proxy. > I need the proxy to communicate with an unmodified server. > And I need this communication to include the hostname for > the administrator of said server to see. Whether the > administrator would have to look in a logfile or a packet > capture in order to see the hostname is not important. An unmodified *final server* or *proxy server*? The final server would obviously work being unmodified. The proxy server could have modifications or not (perhaps not being a ssh server at all). And why do you need the server administrator (the administrator of the proxy?) to see the hostname? (the proxy logs would contain it, but placing the burden on getting the administrator see the hostname, instead of the proxy obtaining it, is strange) > I believe that once I have an answer to how the proxy can > communicate the hostname to the server, then everything > else will follow. Are you trying to solve a XY Problem ? http://xyproblem.info/ > I don't yet know a way to acheive my desired result using > just a ProxyCommand. But with the following change and a > ProxyCommand, I believe I would be able to achieve what I > am looking for. You only need a command that is able to connect to hostname "foo" over proxy "bar", and a proxy server of type "bar" installed in the ipv4 bridging machine. No changes to ssh binaries are needed. From esk-openssh at esk.cs.usu.edu Wed May 27 10:02:00 2015 From: esk-openssh at esk.cs.usu.edu (Eldon Koyle) Date: Tue, 26 May 2015 18:02:00 -0600 Subject: Weak DH primes and openssh In-Reply-To: <87y4kbjgty.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> Message-ID: <20150527000200.GJ1890@esk.usu.edu> On May 26 15:10-0400, Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 14:02:07 -0400, Hubert Kario wrote: > > On Tuesday 26 May 2015 13:43:13 Daniel Kahn Gillmor wrote: > I've been talking with several cryptographers for the last year about > finite-field DH (FFDH) and i haven't heard any suggestion that any of > them think there is likely to be such a class of backdoored moduli. > > > yes, it would basically exclude the chance that the primes are backdoored, > > there's still the chance for the values to be composites > > > > for values to be used on this many machines, I'd say we should have primality > > proofs, not just M-R "guess" > > Does anyone have a pointer to any decent free software for generating > and verifying primality proofs? > > --dkg I am currently running Debian's /etc/ssh/moduli (not sure if it is the same as distributed with openssh) through ecpp-dj . I found the code at http://www.mersenneforum.org/showthread.php?t=18283 (there is a 1.04 version in the download directory), I think he just split it out from his perl module at https://github.com/danaj/Math-Prime-Util-GMP . It is single-threaded, and I'm not sure how well it does with larger primes (at 1000 decimal digits (~3325 bits, if my math skills haven't failed me), his benchmarks show it took 10x as long as primo on the prime he chose). So far, it is running at 15-60 seconds ea for 1535-bit primes on my old i7 950 @ 3.07GHz, not sure how it will do with the larger ones. I'll probably need to move this to a cluster to have it complete in a reasonable amount of time. -- Eldon Koyle -- A fail-safe circuit will destroy others. -- Klipstein From djm at mindrot.org Wed May 27 10:31:36 2015 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 May 2015 10:31:36 +1000 (AEST) Subject: sandox or non-root for single user In-Reply-To: References: Message-ID: On Tue, 26 May 2015, Igor Bukanov wrote: > Hi, > > If I need to provide an ssh access just for a single user and I want > to minimize a chance of malicious code running as root even if it > increases a possibility for malicious code running as that user. Given > that should I try running sshd as that user? Or should I continue to > use UsePrivilegeSeparation=sandbox with sshd running as root? It depends which operating system you are on - if you're running on something with a good platform sandbox (systrace, seatbelt or seccomp-bpf) then you'll have good protection from that even if you are running sshd as the target user. If your platform doesn't have one of the above sandboxed available, then you should run as root to get the benefit of chroot and dropping to an unprivileged user. -d From mancha1 at zoho.com Wed May 27 12:55:39 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 27 May 2015 02:55:39 +0000 Subject: Weak DH primes and openssh In-Reply-To: <87y4kbjgty.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> Message-ID: <20150527025539.GA13936@zoho.com> On Tue, May 26, 2015 at 03:10:01PM -0400, Daniel Kahn Gillmor wrote: > Does anyone have a pointer to any decent free software for generating > and verifying primality proofs? > > --dkg OpenSSH generates strong pseudoprimes to k random bases (that if prime would be "safe primes"). I think Darren uses k=100 (confirmation?) so the way the math works out, each number he generates has at most a 1/(4^100) probability of being composite. In comparison, it's estimated the odds of getting crushed to death by a vending machine are 1 in 112 million. Death-by-chocolate-bar is about 14,347,661,109,455,270,317,338,947,253,046,094,665,376,812,444,489,221 more likely to happen to you than having a given "Darren-prime" turn out to be composite. The take-away, of course, is to always snack responsibly. Nonetheless, the most we can currently say is the numbers are almost surely prime. Certainty would be nice. ECPP is the fastest prime proving algorithm that also provides certificates (I think) and PRIMO is the king-of-the-hill implementation (others exist but are significantly slower with bigger numbers). Though as you mentioned PRIMO's not libre (just free), the math in the certificates is open-source and that's really the critical part here. The proofs themselves are sequences of steps that at each step (except the last) prove a number N is prime if a smaller number R is prime. Every subsequent step takes its N from the previous step's R and this continues until we arrive at an R < 34*10^13 because such an R can be proven prime if it is a strong pseudoprime to the base of the 7 primes smaller than 19 (i.e. 2, 3, 5, 7, 11, 13, 17) TL;DR With PRIMO's help, I've proved the first 200 strong pseudoprimes in the latest v1.12 moduli file are indeed prime. Darren, so far you're batting a thousand! I've uploaded my proofs to factordb.com for independent verification and complementary confirmation proofs. For example, check out the 4th prime in Darren's new moduli file: https://tinyurl.com/pg66aq5 As I write this I've checked through #209. Those with spare CPU cycles on 64-bit Linux can help with the 65 strong pseudoprimes remaining (#210 to #274). Those who wish to help should get PRIMO [1] and grab the full set of input files I made: http://sf.net/projects/mancha/files/misc/openssh-moduli-20150522_primo.tar.bz2 The 7680-bit moduli (#225 - #248) and 8192-bit moduli (#249 - #274) are up for grabs. Probably best if you claim your range to avoid effort duplication. --mancha PS In addition to factordb.com, ecpp-dj [2] can verify PRIMO certs. ecpp-dj also proves primality but it is slower than PRIMO and more importantly its cert format can't be independently verified. ------ [1] http://www.ellipsa.eu/public/primo/files/primo-411-lx64.7z [2] http://sti15.com/nt/ecpp-dj-1.04.tar.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dtucker at zip.com.au Wed May 27 13:12:52 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 27 May 2015 13:12:52 +1000 Subject: Weak DH primes and openssh In-Reply-To: <20150527025539.GA13936@zoho.com> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> <20150527025539.GA13936@zoho.com> Message-ID: On Wed, May 27, 2015 at 12:55 PM, mancha wrote: > I think Darren uses k=100 (confirmation?) Yes. I use all of the default settings to ssh-keygen and the default for number of rounds is 100. The exact commands used for the single threaded version are here: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/moduli-gen/ As previously mentioned I have a wrapper script to split up work over multiple processors but it only adds -J/-j flags for "start here" and "process this many" which I run over multiple machines. I will tidy up this script and publish that too when I get a chance. Once I have the complete list assembled I re-screen it on OpenBSD and make sure the output agrees (other than the timestamp). I would be happy to add a verification by an independent software implementation (for practical purposes it'd probably need to be free-as-in-speech; it sounds like ecpp-dj might be a candidate). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kasperd at fzcpf.25.may.2015.kasperd.net Wed May 27 17:40:39 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 09:40:39 +0200 Subject: Name based SSH proxy In-Reply-To: <556504FF.6020105@gmail.com> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <556504FF.6020105@gmail.com> Message-ID: <20150527074039.GA3481@colin.search.kasperd.net> On 27/05/15 01.42, ?ngel Gonz?lez wrote: > Why do you want the hostname being used to "be visible to the administrator > of the SSH server"? In case the AAAA record used by the proxy to find the server for some reason points to the wrong IP address, I want to ensure that the administrator of the server has the opportunity to see the DNS record causing connections to end up on their server. That's only possible if the hostname is sent to the server somehow. > > I assumed you wanted to send the final hostname to the *proxying SSH > server*. Sorry if I didn't express that clearly enough. I need the hostname to be visible to both proxy and the target server. > In which case, you don't need such thing if using a HTTP CONNECT proxy (the > hostname is now given to the HTTP proxy). And if you use a ssh server > like the ssh > tunneling I proposed, the final hostname is already provided, too. Communicating the hostname to the proxy is probably going to be the easy part. The tricky part is to make it visible to the administrator of the target server. > > If you want instead to give the hostname used to the *final* sshd, > that's a different > requirement for which you provided no rationale (and I suspect you are > not really > interested in). That's definitely what I am interested in. The rationale is that the administrator of the final server is to have access to this information. > > > Much more interesting at the final end than the requested would be to > have the > original client IP (ie. X-Forwarded-For) but that would open a different > can of worms > (and required software changes) about proxies whose forwarded IPs should > be trusted. Actually for my specific ussage, that is a solved problem. Communication from client to proxy is IPv4. Communication from proxy to server is IPv6. The proxy simply embed the client IPv4 as the last 32 bits of the client IPv6 visible to the server. > Something I would prefer not to enter into. You don't have to. At least I am not going to be the one asking you to. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From kasperd at kdxdx.23.may.2015.kasperd.net Wed May 27 18:32:01 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 10:32:01 +0200 Subject: Name based SSH proxy In-Reply-To: <55650A0B.1040107@gmail.com> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <87h9qzj7mb.fsf@alice.fifthhorseman.net> <20150526232234.GA3493@colin.search.kasperd.net> <55650A0B.1040107@gmail.com> Message-ID: <20150527083201.GB3481@colin.search.kasperd.net> On 27/05/15 02.04, ?ngel Gonz?lez wrote: > On 27/05/15 01:22, Kasper Dupont wrote: > >Whether the client side changes can be done as a > >ProxyCommand remains an open question. But it is certain > >that a modification of the ssh client would cover all my > >needs. > ....with a modified server that acts as a proxy. The proxy is not going to be based on an SSH server. Rather the proxy is going to be a multi-protocol proxy which I already wrote for dispatching TCP connections to backends based on hostname. That proxy does just enough protocol detection to pick out the hostname. Works great for HTTP and HTTPS. I have proof of concept code showing that with only a minor change on the *client* side, connections can go through my unmodified HTTP proxy and be terminated on an unmodified ssh server. That proof of concept code is the baseline which I am going to compare any other solution against. In order for me to consider an alternative to that proof of concept code, the alternative has to offer at least one advantage over my proof of concept code and not violate any of my requirements. The most tricky of my requirements is likely the one about ensuring the hostname will be visible to the administrator of the SSH server without requiring any code changes on the SSH server. I welcome any suggestions to how I can address that requirement. A solution which could be implemented as a ProxyCommand rather than as a modification of the client itself would be an advantage. I have an idea as to how my proof of concept could be modified to work as a ProxyCommand. It remains to be seen, whether it is going to work. > > > >I need the proxy to communicate with an unmodified server. > >And I need this communication to include the hostname for > >the administrator of said server to see. Whether the > >administrator would have to look in a logfile or a packet > >capture in order to see the hostname is not important. > An unmodified *final server* or *proxy server*? The final server > would obviously work being unmodified. The final server needs to work unmodified. Getting that part to work is trivial if you ignore the requirement about the hostname being communicated to the final server. But once the hostname has to be communicated to the final server, it is not completely trivial. It is still doable since sending the hostname as part of a field which is going to be ignored by the server will work. > The proxy server could have > modifications or not (perhaps not being a ssh server at all). The proxy is not going to be an SSH server. The baseline for the proxy is a server designed to be a multi-protocol name based TCP frontend. It works with any TCP protocol in which the client speaks first and the client send the hostname before hearing from the server. So far the protocols I found satisfying those requirements are HTTP and HTTPS. > And why do you need the server administrator (the administrator > of the proxy?) to see the hostname? I am talking about the administrator of the server not the proxy. It needs to be visible to that administrator mainly such that in case of misdirected connections the administator can find the AAAA record directing the client to said server. > (the proxy logs would contain it, > but placing the burden on getting the administrator see the hostname, > instead of the proxy obtaining it, is strange) The proxy logs will certainly contain the hostname, but the administrator of the server could be anybody and wouldn't have access to the proxy logs. Sure they can ask for the hostname to be looked up in the proxy logs. But that would be a needless extra step, if the server administrator can simply look at the traffic being sent to the server in order to know the hostname. > > >I believe that once I have an answer to how the proxy can > >communicate the hostname to the server, then everything > >else will follow. > Are you trying to solve a XY Problem ? No. I have a specific set of requirements, and I am looking for a solution to address that set of requirements. From the list of requirements I am focusing on that one requirement because none of the proposed solutions have addressed it. And my expectation is, that once that requirement has been addressed it is going to be obvious how the rest of the problems can be addressed. > >I don't yet know a way to acheive my desired result using > >just a ProxyCommand. But with the following change and a > >ProxyCommand, I believe I would be able to achieve what I > >am looking for. > You only need a command that is able to connect to hostname > "foo" over proxy "bar", and a proxy server of type "bar" installed > in the ipv4 bridging machine. That does not address the requirement that the hostname is communicated to the server. Sure if that requirement is ignored, there will be plenty of possible approaches. But I am not going to ignore that requirement. Suggestions to how it can be solved if that requirement is ignored are not helping me because I have considered them before and rejected them because they did not satisfy my requirements. It would be much more helpful to me if I got a suggested solution to that single requirement which ignored everything else. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dirkx at webweaving.org Wed May 27 19:07:22 2015 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 27 May 2015 11:07:22 +0200 Subject: Name based SSH proxy In-Reply-To: <20150526214240.GA3469@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> Message-ID: > On 26 May 2015, at 23:42, Kasper Dupont wrote: > > On 26/05/15 15.50, Daniel Kahn Gillmor wrote: >> The argument that the DNS lookup leaks this metadata is a bad argument: >> if we followed this line of reasoning, then every problem that has >> multiple contributors could never be solved (A says "but my fixing >> things is useless if B does nothing", while B says "but my fixing things As a practical suggestion - we ran for a while with a hack where we abuse the version human readable string with a base64 string of a _salted_ hash of the server we where trying to get to. Sharing both salt and hash. This let the server figure out the right key to present without too much ado; but without leaking all that much*. The idea was to make it a tiny bit more costly to get a decent selector really early in a connection. However - as keeping a few 10?s of packets in state is no longer that costly; key init and exchange always start at a packet; And the DH modulus (identical but for its last for bytes) in the DH group exchange (31) and what not follow soon thereafter; it seems all a bit superfluous. Dw. *; Except of course - the fairly unqiue Key Kexchange Init and then the very unique Key Exchange Init of the server following in the clear - so one has to be careful with these; or intentionally reuse them. Which is why it fell in disuse soon thereafter. From hkario at redhat.com Wed May 27 19:23:41 2015 From: hkario at redhat.com (Hubert Kario) Date: Wed, 27 May 2015 11:23:41 +0200 Subject: Weak DH primes and openssh In-Reply-To: <87y4kbjgty.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> Message-ID: <10094608.Ne5zRi2mUz@pintsize.usersys.redhat.com> On Tuesday 26 May 2015 15:10:01 Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 14:02:07 -0400, Hubert Kario wrote: > > On Tuesday 26 May 2015 13:43:13 Daniel Kahn Gillmor wrote: > >> On Tue 2015-05-26 12:57:05 -0400, Hubert Kario wrote: > >> > creating composites that will pass even 100000 rounds of Miller-Rabin > >> > is > >> > relatively simple.... > >> > (assuming the values for M-R tests are picked randomly) > >> > >> Can you point me to the algorithms for doing that? > > > > OEIS A014233 > > Hm, this is a sequence, but not an algorithm. It looks to me like it is > not exhaustive, just a list of those integers which are known to have > the stated property ("Smallest odd number for which Miller-Rabin > primality test on bases <= n-th prime does not reveal compositeness"). > > Taking the final integer in that sequence (a(11)) fails even the default > > 25-round M-R test in gmp: > >>> k = gmpy2.mpz(3825123056546413051) > >>> gmpy2.is_prime(k) > > False I'm quite sure that this means that gmpy doesn't use pure M-R with randomly selected witnesses. > Indeed, the arxiv suggests that in 2012 people were still writing proofs > about a(11) for this sequence: > > http://arxiv.org/abs/1207.0063 > > but i see no evidence that an algorithm for generating a(n) where n is > arbitrarily large exists. Does such a thing exist? As far as I know, the most computationally efficient algorithm is basically going over every non trivially composite number and checking all witnesses point is that this is a proof that such numbers exists, it also shows that the resistance to witnesses is not probabilistically independent. > > yes, using ECPP and distributing proof with the prime (or just placing it > > on the project website) is a reasonable minimum, that still leaves out > > the possibility of a backdoor if the initial seed value is random > > it sounds like we're heading into the same territory as the ECDH curve > selection discussion -- the theory you're suggesting is that some > safe-prime moduli could themselves have a backdoor that we don't know > about. Am i understanding you correctly? yes, it's so that they are "rigid" in ECC nomenclature > I've been talking with several cryptographers for the last year about > finite-field DH (FFDH) and i haven't heard any suggestion that any of > them think there is likely to be such a class of backdoored moduli. Hmm, I have a distinct recollection of reading of a possibility of a small subgroup attacks on primes (as in very few primes have this property, so randomly selected one are almost certainly not problematic, but if you can pick any prime, you can find them) Maybe what they mean is that this may does not apply to Sophie Germain primes, but to "DSA style" primes, I haven't dug too deep into this. Creating it pseudo-randomly from nothing up my sleeve numbers fixes this issue anyway. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From dtucker at zip.com.au Wed May 27 19:58:01 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 27 May 2015 19:58:01 +1000 Subject: Weak DH primes and openssh In-Reply-To: <555F3D93.7050307@cam.ac.uk> References: <555F3D93.7050307@cam.ac.uk> Message-ID: On Sat, May 23, 2015 at 12:30 AM, David McBride wrote: > On Fri, May 22, 2015 at 12:27:01, Darren Tucker > wrote: > > > Note that PuTTY does do Diffie-Hellman Group Exchange, but until very > > recently (ie after their 0.64 release) they didn't do the one that was > > actually standardized in RFC4419. OpenSSH recently removed support for > > that non-standard one and as a result we don't offer DHGEX to PuTTY > > versions <= 0.64 so they'll fall back to group14 (2k bit fix group). > > I think this is wrong. > I've looked into it some more and unfortunately it's not wrong. > This commit [0] from 2005 appears to show the addition of > diffie-hellman-group-exchange-sha256 support to PuTTY. > diffie-hellman-group-exchange-sha256 and diffie-hellman-group-exchange-sha1 use the same message type defined in RFC4419 to request a group, and PuTTY up to 0.64 uses the same deprecated message type (30) for both. See > https://anongit.mindrot.org/openssh.git/commit/?id=318be28cda1fd9108f2e6f2f86b0b7589ba2aed0 > > + if ((datafellows & SSH_OLD_DHGEX) != 0) { > + p = filter_proposal(p, "diffie-hellman-group-exchange-sha256"); > + p = filter_proposal(p, "diffie-hellman-group-exchange-sha1"); > + } > > > > > I've also just successfully connected to a local test OpenSSH server > (v6.7p1, as packaged by Debian) with only > diffie-hellman-group-exchange-sha256 enabled with an older release of > PuTTY (0.63) without any issue. > The removal of the pre-RFC4419 message type in OpenSSH was made after the last release. Please retry your test with a current development snapshot. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kasperd at fzcpf.25.may.2015.kasperd.net Wed May 27 20:09:00 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 12:09:00 +0200 Subject: Name based SSH proxy In-Reply-To: References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> Message-ID: <20150527100900.GA4514@colin.search.kasperd.net> On 27/05/15 11.07, Dirk-Willem van Gulik wrote: > As a practical suggestion - we ran for a while with a hack where we abuse the version human readable string with a > base64 string of a _salted_ hash of the server we where trying to get to. > > Sharing both salt and hash. > > This let the server figure out the right key to present without too much ado; but without leaking all that much*. The idea was to make it a tiny bit more costly to get a decent selector really early in a connection. That approach seems to rely on the proxy knowing the full list of possible hostnames in advance. In my case the proxy doesn't know the list of hostnames in advance. > > However - as keeping a few 10?s of packets in state is no longer that costly; key init and exchange always start at a packet; And the DH modulus (identical but for its last for bytes) in the DH group exchange (31) and what not follow soon thereafter; it seems all a bit superfluous. That sentence I did not understand. Could you elaborate or explain it differently? -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From kasperd at fzcpf.25.may.2015.kasperd.net Wed May 27 20:27:55 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 12:27:55 +0200 Subject: [SUSPECTED SPAM] Re: Name based SSH proxy In-Reply-To: <20150525235005.13809.qmail@stuge.se> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525235005.13809.qmail@stuge.se> Message-ID: <20150527102755.GA4741@colin.search.kasperd.net> On 26/05/15 01.50, Peter Stuge wrote: > Kasper Dupont wrote: > > +send_client_banner(int connection_out, int minor1, const char *host) > > { > > /* Send our own protocol version identification. */ > > if (compat20) { > > - xasprintf(&client_version_string, "SSH-%d.%d-%.100s\r\n", > > - PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION); > > + xasprintf(&client_version_string, > > + "SSH-%d.%d-%.100s {\"SNI\": \"%.133s\"}\r\n", > > + PROTOCOL_MAJOR_2, PROTOCOL_MINOR_2, SSH_VERSION, host); > > You propose introducing JSON injection. Really? Felt like a better idea than XML. > > Aside from all the other valid criticism, JSON is a bad fit. Frankly. I don't care about the format. JSON was the best I could come up with given that it is supposed to be human readable and it is a good idea to use an established standard which is extensible. If you can suggest a better format, I'd happily change it. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dirkx at webweaving.org Wed May 27 20:41:07 2015 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 27 May 2015 12:41:07 +0200 Subject: Name based SSH proxy In-Reply-To: <20150527100900.GA4514@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <20150527100900.GA4514@colin.search.kasperd.net> Message-ID: <2D5901AD-0B46-4724-8D18-A95259AADE9E@webweaving.org> On 27 May 2015, at 12:09, Kasper Dupont wrote: > > On 27/05/15 11.07, Dirk-Willem van Gulik wrote: >> As a practical suggestion - we ran for a while with a hack where we abuse the version human readable string with a >> base64 string of a _salted_ hash of the server we where trying to get to. >> >> Sharing both salt and hash. >> >> This let the server figure out the right key to present without too much ado; but without leaking all that much*. The idea was to make it a tiny bit more costly to get a decent selector really early in a connection. > > That approach seems to rely on the proxy knowing the full > list of possible hostnames in advance. In my case the > proxy doesn't know the list of hostnames in advance. Correct. >> However - as keeping a few 10?s of packets in state is no longer that costly; key init and exchange always start at a packet; And the DH modulus (identical but for its last four bytes) in the DH group exchange (31) and what not follow soon thereafter; it seems all a bit superfluous. > > That sentence I did not understand. Could you elaborate > or explain it differently? One could argue that putting the host name as plain text in the initial unencrypted exchange is leaking something (ignoring the DNS aspect here). As this a) reveals whom you are talking to and b) may be a good trigger/selector for something pen-register/trap/trace. However a bit later in the exchange we get, in the clear, a somewhat finger printable list of possible cyphers supported (Key Exchange Init) is flashed by the server in the clear. Followed a packet later by the Diffie-Hellman Group Exchange Group; which contains the DH modulus in the clear (from the list of some 200 pre calculated safe primes, ?ssh/moduli'; in groups of 40; that are identical but for the last 4 bytes or so). So I guess that that makes not revealing some identifier as to whom you want to talk a bit of a moot point; as a few packets later it is revealed anyway. Dw. From aris at 0xbadc0de.be Wed May 27 22:06:12 2015 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Wed, 27 May 2015 14:06:12 +0200 Subject: Weak DH primes and openssh In-Reply-To: <20150527025539.GA13936@zoho.com> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> <20150527025539.GA13936@zoho.com> Message-ID: <5565B334.2080703@0xbadc0de.be> If the primality test is such a problem, one could implement a variant to the AKS polynomial time primality test: https://en.wikipedia.org/wiki/AKS_primality_test https://math.dartmouth.edu/~carlp/aks041411.pdf This test (and variants) are not statistical. I have no idea if they work in reasonable time on 1024-4096bits prime candidates. Aris Le 27/05/15 04:55, mancha a ?crit : > On Tue, May 26, 2015 at 03:10:01PM -0400, Daniel Kahn Gillmor wrote: >> Does anyone have a pointer to any decent free software for generating >> and verifying primality proofs? >> >> --dkg > > OpenSSH generates strong pseudoprimes to k random bases (that if prime > would be "safe primes"). I think Darren uses k=100 (confirmation?) so > the way the math works out, each number he generates has at most a > 1/(4^100) probability of being composite. > > In comparison, it's estimated the odds of getting crushed to death by a > vending machine are 1 in 112 million. > > Death-by-chocolate-bar is about > 14,347,661,109,455,270,317,338,947,253,046,094,665,376,812,444,489,221 > more likely to happen to you than having a given "Darren-prime" turn out > to be composite. > > The take-away, of course, is to always snack responsibly. > > Nonetheless, the most we can currently say is the numbers are almost > surely prime. Certainty would be nice. > > ECPP is the fastest prime proving algorithm that also provides > certificates (I think) and PRIMO is the king-of-the-hill implementation > (others exist but are significantly slower with bigger numbers). > > Though as you mentioned PRIMO's not libre (just free), the math in the > certificates is open-source and that's really the critical part here. > > The proofs themselves are sequences of steps that at each step (except > the last) prove a number N is prime if a smaller number R is prime. > Every subsequent step takes its N from the previous step's R and this > continues until we arrive at an R < 34*10^13 because such an R can be > proven prime if it is a strong pseudoprime to the base of the 7 primes > smaller than 19 (i.e. 2, 3, 5, 7, 11, 13, 17) > > TL;DR > > With PRIMO's help, I've proved the first 200 strong pseudoprimes in > the latest v1.12 moduli file are indeed prime. Darren, so far you're > batting a thousand! > > I've uploaded my proofs to factordb.com for independent verification > and complementary confirmation proofs. > > For example, check out the 4th prime in Darren's new moduli file: > > https://tinyurl.com/pg66aq5 > > As I write this I've checked through #209. Those with spare CPU cycles > on 64-bit Linux can help with the 65 strong pseudoprimes remaining > (#210 to #274). > > Those who wish to help should get PRIMO [1] and grab the full set of > input files I made: > > http://sf.net/projects/mancha/files/misc/openssh-moduli-20150522_primo.tar.bz2 > > The 7680-bit moduli (#225 - #248) and 8192-bit moduli (#249 - #274) are > up for grabs. Probably best if you claim your range to avoid effort > duplication. > > --mancha > > PS In addition to factordb.com, ecpp-dj [2] can verify PRIMO certs. > ecpp-dj also proves primality but it is slower than PRIMO and more > importantly its cert format can't be independently verified. > > ------ > > [1] http://www.ellipsa.eu/public/primo/files/primo-411-lx64.7z > [2] http://sti15.com/nt/ecpp-dj-1.04.tar.gz > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From kasperd at fzcpf.25.may.2015.kasperd.net Wed May 27 22:11:27 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 14:11:27 +0200 Subject: Name based SSH proxy In-Reply-To: <2D5901AD-0B46-4724-8D18-A95259AADE9E@webweaving.org> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <20150527100900.GA4514@colin.search.kasperd.net> <2D5901AD-0B46-4724-8D18-A95259AADE9E@webweaving.org> Message-ID: <20150527121127.GA3493@colin.search.kasperd.net> On 27/05/15 12.41, Dirk-Willem van Gulik wrote: > One could argue that putting the host name as plain text in the initial unencrypted exchange is leaking something (ignoring the DNS aspect here). > > As this a) reveals whom you are talking to and b) may be a good trigger/selector for something pen-register/trap/trace. > > However a bit later in the exchange we get, in the clear, a somewhat finger printable list of possible cyphers supported (Key Exchange Init) is flashed by the server in the clear. Followed a packet later by the Diffie-Hellman Group Exchange Group; which contains the DH modulus in the clear (from the list of some 200 pre calculated safe primes, ?ssh/moduli'; in groups of 40; that are identical but for the last 4 bytes or so). > > So I guess that that makes not revealing some identifier as to whom you want to talk a bit of a moot point; as a few packets later it is revealed anyway. Got it. And not to forget the host public key of the server is also being sent in clear during the key exchange. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dirkx at webweaving.org Wed May 27 22:16:14 2015 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 27 May 2015 14:16:14 +0200 Subject: Name based SSH proxy In-Reply-To: <20150527121127.GA3493@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <20150527100900.GA4514@colin.search.kasperd.net> <2D5901AD-0B46-4724-8D18-A95259AADE9E@webweaving.org> <20150527121127.GA3493@colin.search.kasperd.net> Message-ID: <654C1DC0-8438-4E95-BE8B-425C63795D53@webweaving.org> > On 27 May 2015, at 14:11, Kasper Dupont wrote: > > On 27/05/15 12.41, Dirk-Willem van Gulik wrote: >> One could argue that putting the host name as plain text in the initial unencrypted exchange is leaking something (ignoring the DNS aspect here). >> >> As this a) reveals whom you are talking to and b) may be a good trigger/selector for something pen-register/trap/trace. >> >> However a bit later in the exchange we get, in the clear, a somewhat finger printable list of possible cyphers supported (Key Exchange Init) is flashed by the server in the clear. Followed a packet later by the Diffie-Hellman Group Exchange Group; which contains the DH modulus in the clear (from the list of some 200 pre calculated safe primes, ?ssh/moduli'; in groups of 40; that are identical but for the last 4 bytes or so). >> >> So I guess that that makes not revealing some identifier as to whom you want to talk a bit of a moot point; as a few packets later it is revealed anyway. > > Got it. And not to forget the host public key of the server > is also being sent in clear during the key exchange. Agreed. In our actual usecase/reason-to-ditch the SNI plan - it was more a worry about moduli being distributed with the OS (like http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/moduli-gen/ ) and using that to fingerprint specific releases. Dw. From mancha1 at zoho.com Thu May 28 01:48:09 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 27 May 2015 15:48:09 +0000 Subject: Weak DH primes and openssh In-Reply-To: <5565B334.2080703@0xbadc0de.be> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> <20150527025539.GA13936@zoho.com> <5565B334.2080703@0xbadc0de.be> Message-ID: <20150527154809.GB5611@zoho.com> On Wed, May 27, 2015 at 02:06:12PM +0200, Aris Adamantiadis wrote: > If the primality test is such a problem, one could implement a variant > to the AKS polynomial time primality test: > https://en.wikipedia.org/wiki/AKS_primality_test > https://math.dartmouth.edu/~carlp/aks041411.pdf > > This test (and variants) are not statistical. I have no idea if they > work in reasonable time on 1024-4096bits prime candidates. > > Aris > > Le 27/05/15 04:55, mancha a ?crit : > > On Tue, May 26, 2015 at 03:10:01PM -0400, Daniel Kahn Gillmor wrote: > >> Does anyone have a pointer to any decent free software for generating > >> and verifying primality proofs? > >> > >> --dkg > > > > OpenSSH generates strong pseudoprimes to k random bases (that if prime > > would be "safe primes"). I think Darren uses k=100 (confirmation?) so > > the way the math works out, each number he generates has at most a > > 1/(4^100) probability of being composite. > > > > In comparison, it's estimated the odds of getting crushed to death by a > > vending machine are 1 in 112 million. > > > > Death-by-chocolate-bar is about > > 14,347,661,109,455,270,317,338,947,253,046,094,665,376,812,444,489,221 > > more likely to happen to you than having a given "Darren-prime" turn out > > to be composite. > > > > The take-away, of course, is to always snack responsibly. > > > > Nonetheless, the most we can currently say is the numbers are almost > > surely prime. Certainty would be nice. > > > > ECPP is the fastest prime proving algorithm that also provides > > certificates (I think) and PRIMO is the king-of-the-hill implementation > > (others exist but are significantly slower with bigger numbers). > > > > Though as you mentioned PRIMO's not libre (just free), the math in the > > certificates is open-source and that's really the critical part here. > > > > The proofs themselves are sequences of steps that at each step (except > > the last) prove a number N is prime if a smaller number R is prime. > > Every subsequent step takes its N from the previous step's R and this > > continues until we arrive at an R < 34*10^13 because such an R can be > > proven prime if it is a strong pseudoprime to the base of the 7 primes > > smaller than 19 (i.e. 2, 3, 5, 7, 11, 13, 17) > > > > TL;DR > > > > With PRIMO's help, I've proved the first 200 strong pseudoprimes in > > the latest v1.12 moduli file are indeed prime. Darren, so far you're > > batting a thousand! > > > > I've uploaded my proofs to factordb.com for independent verification > > and complementary confirmation proofs. > > > > For example, check out the 4th prime in Darren's new moduli file: > > > > https://tinyurl.com/pg66aq5 > > > > As I write this I've checked through #209. Those with spare CPU cycles > > on 64-bit Linux can help with the 65 strong pseudoprimes remaining > > (#210 to #274). > > > > Those who wish to help should get PRIMO [1] and grab the full set of > > input files I made: > > > > > http://sf.net/projects/mancha/files/misc/openssh-moduli-20150522_primo.tar.bz2 > > > > The 7680-bit moduli (#225 - #248) and 8192-bit moduli (#249 - #274) are > > up for grabs. Probably best if you claim your range to avoid effort > > duplication. > > > > --mancha > > > > PS In addition to factordb.com, ecpp-dj [2] can verify PRIMO certs. > > ecpp-dj also proves primality but it is slower than PRIMO and more > > importantly its cert format can't be independently verified. > > > > ------ > > > > [1] http://www.ellipsa.eu/public/primo/files/primo-411-lx64.7z > > [2] http://sti15.com/nt/ecpp-dj-1.04.tar.gz Though PRIMES IN P has been heavily optimized since it's first version, it's still O(log^7 n) or so. Compare that to Fast-ECPP which is around O(log^4 n). Also, for our purposes we're going up to 8192 bit numbers not just 4096. Unfortunately, neither PRIMES IN P nor tests such as the near poly-time APR generate proofs. So, there's no quick way to verify someone else's result. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu May 28 03:11:43 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 May 2015 13:11:43 -0400 Subject: Weak DH primes and openssh In-Reply-To: <10094608.Ne5zRi2mUz@pintsize.usersys.redhat.com> References: <555DDD09.3090606@debian.org> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> <10094608.Ne5zRi2mUz@pintsize.usersys.redhat.com> Message-ID: <87pp5mhrn4.fsf@alice.fifthhorseman.net> On Wed 2015-05-27 05:23:41 -0400, Hubert Kario wrote: > On Tuesday 26 May 2015 15:10:01 Daniel Kahn Gillmor wrote: >> On Tue 2015-05-26 14:02:07 -0400, Hubert Kario wrote: >> > OEIS A014233 >> >> Hm, this is a sequence, but not an algorithm. It looks to me like it is >> not exhaustive, just a list of those integers which are known to have >> the stated property ("Smallest odd number for which Miller-Rabin >> primality test on bases <= n-th prime does not reveal compositeness"). >> >> Taking the final integer in that sequence (a(11)) fails even the default >> >> 25-round M-R test in gmp: >> >>> k = gmpy2.mpz(3825123056546413051) >> >>> gmpy2.is_prime(k) >> >> False > > I'm quite sure that this means that gmpy doesn't use pure M-R with randomly > selected witnesses. https://gmplib.org/manual/Prime-Testing-Algorithm.html#Prime-Testing-Algorithm suggests is chooses a random base, but it also runs some non-M-R tests before executing M-R: http://sources.debian.net/src/gmp/2:6.0.0%2Bdfsg-6/mpz/pprime_p.c/ GMP's M-R tests are using randomly selected witnesses, though: http://sources.debian.net/src/gmp/2:6.0.0%2Bdfsg-6/mpz/millerrabin.c/#L92 > Hmm, I have a distinct recollection of reading of a possibility of a > small subgroup attacks on primes (as in very few primes have this > property, so randomly selected one are almost certainly not > problematic, but if you can pick any prime, you can find them) > > Maybe what they mean is that this may does not apply to Sophie Germain > primes, but to "DSA style" primes, I haven't dug too deep into > this. Creating it pseudo-randomly from nothing up my sleeve numbers > fixes this issue anyway. I think you mean "safe primes" where you say "Sophie Germain primes" -- if q = (p-1)/2, and p and q are primes, then p is a "safe prime" and q is a "Sophie Germain prime". Small subgroup attacks are not possible for safe primes as long as you test your peer's public share and the generator to ensure that they are in the range (exclusive) 1 < x < p-1. This is because totient(p) = p-1 (because p is prime), and p-1 has only two factors: 2 and q. So there exists one small subgroup, but it's of order 2, and its generator is p-1 (the subgroup cycles between p-1 and 1). All other elements are generators of order either q or p-1. There are no other subgroups, iiuc. If this is the only attack you're trying to address, and you've already limited yourself to safe primes, then NUMS properties don't really add anything. The NUMS approach is there are to try to avoid the possibility of other, unknown cryptanalytic attacks against some infrequent type of group, so that the entity who defines the group can't force you into this secret corner case if they have special knowledge. --dkg From keisial at gmail.com Thu May 28 06:42:06 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 27 May 2015 22:42:06 +0200 Subject: Name based SSH proxy In-Reply-To: <20150527074039.GA3481@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <556504FF.6020105@gmail.com> <20150527074039.GA3481@colin.search.kasperd.net> Message-ID: <55662C1E.9020902@gmail.com> On 27/05/15 09:40, Kasper Dupont wrote: > On 27/05/15 01.42, ?ngel Gonz?lez wrote: >> Why do you want the hostname being used to "be visible to the administrator >> of the SSH server"? > In case the AAAA record used by the proxy to find the > server for some reason points to the wrong IP address, > I want to ensure that the administrator of the [target] server > has the opportunity to see the DNS record causing > connections to end up on their server. That's only > possible if the hostname is sent to the server somehow. Well, John Doe connecting through your proxy to 192.168.1.1 because foo.example.org is pointing there instead of 192.168.111.111 is no different from John Doe doing exactly that with a different connection. If the dns record is wrong, there's little 192.168.1.1 can do >> In which case, you don't need such thing if using a HTTP CONNECT proxy (the >> hostname is now given to the HTTP proxy). And if you use a ssh server >> like the ssh >> tunneling I proposed, the final hostname is already provided, too. > Communicating the hostname to the proxy is probably going > to be the easy part. Indeed, that's trivial. > The tricky part is to make it visible to the administrator of the target server. Yes. ssh protocol is quite guarded against alterations from the outside. >> If you want instead to give the hostname used to the *final* sshd, >> that's a different >> requirement for which you provided no rationale (and I suspect you are >> not really >> interested in). > That's definitely what I am interested in. The rationale > is that the administrator of the final server is to have > access to this information. As above, I don't think it could do much with it, and there will be exactly the same, but. Would you consider acceptable for the proxy to send an udp packet to the target server (eg. udp 514) informing it of the requested hostname it's forwarding? From dkg at fifthhorseman.net Thu May 28 07:08:25 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 May 2015 17:08:25 -0400 Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group In-Reply-To: <48704.1432669189@eng-mail01.juniper.net> References: <48704.1432669189@eng-mail01.juniper.net> Message-ID: <87siahhgom.fsf@alice.fifthhorseman.net> On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote: > Hi Folks, > > The generator value of 5 does not lead to a q-ordered subgroup which is > needed to pass tests in > > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf I pulled revision 2 of this document from here: https://dx.doi.org/10.6028/nist.sp.800-56ar2 The "FFC Domain Parameter Generation" section does say: g is a generator of the cyclic subgroup of GF(p)* of order q, But i don't see a recommendation of why this matters. Surely we don't want the subgroup of order 2, but what is wrong with using a subgroup of order 2q = p-1? There's clearly no strong security advantage to the 2q subgroup -- it's just one bit larger -- but is there an attack that works against the 2q subgroup that doesn't work against the q subgroup? If this is a known concern, i'd be happy with just a pointer to a paper or web page explaining the risks of the larger group. otoh, if the goal is just to ensure we have word-for-word compliance with SP800-56A, then it's clear that choosing a different generator is the way to go (and without much of a security cost). but i'd like to know if there's a reason other than blind-spec-compliance. Pointers? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From kasperd at fzcpf.25.may.2015.kasperd.net Thu May 28 07:38:54 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Wed, 27 May 2015 23:38:54 +0200 Subject: Name based SSH proxy In-Reply-To: <55662C1E.9020902@gmail.com> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <556504FF.6020105@gmail.com> <20150527074039.GA3481@colin.search.kasperd.net> <55662C1E.9020902@gmail.com> Message-ID: <20150527213854.GA3486@colin.search.kasperd.net> On 27/05/15 22.42, ?ngel Gonz?lez wrote: > On 27/05/15 09:40, Kasper Dupont wrote: > >On 27/05/15 01.42, ?ngel Gonz?lez wrote: > >>Why do you want the hostname being used to "be visible to the > >>administrator > >>of the SSH server"? > >In case the AAAA record used by the proxy to find the > >server for some reason points to the wrong IP address, > >I want to ensure that the administrator of the [target] server > >has the opportunity to see the DNS record causing > >connections to end up on their server. That's only > >possible if the hostname is sent to the server somehow. > Well, John Doe connecting through your proxy to 192.168.1.1 My proxy only connects to IPv6 backends, but let's not dwell too much on that detail. > because foo.example.org is pointing there instead of 192.168.111.111 > is no different from John Doe doing exactly that with a different > connection. > > If the dns record is wrong, there's little 192.168.1.1 can do I'd say that depends on the circumstances. I certainly think the administrator of the target host is in a better position to do something if he knows about the DNS record than if he doesn't. > > > >>In which case, you don't need such thing if using a HTTP CONNECT proxy > >>(the > >>hostname is now given to the HTTP proxy). And if you use a ssh server > >>like the ssh > >>tunneling I proposed, the final hostname is already provided, too. > >Communicating the hostname to the proxy is probably going > >to be the easy part. > Indeed, that's trivial. > > >The tricky part is to make it visible to the administrator of the target > >server. > Yes. ssh protocol is quite guarded against alterations from the outside. One week ago I thought any change whatsoever that an intermediate host would make to the stream of bytes between SSH client and SSH server would be detected and cause the SSH connection to be terminated. But I have since learned, that it is not that picky. Not every byte exchanged during the key exchange is subject to integrity check. Changing any of the bytes fed into the key derivation algorithm is obviously going to break the connection when the first MAC is validated with a mismatching key. Changing the number of messages send during the key exchange is also going to break the connection because the first MAC validation would fail due to the message sequence number mismatching between client and server. But any other modification of the bytes transfered during key exchange will go unnoticed. > > Would you consider acceptable for the proxy to send an udp packet to the > target server > (eg. udp 514) informing it of the requested hostname it's forwarding? That's not a bad idea. It's an idea I hadn't thought about before, but now I will. I'll have to think about what advantages and disadvantages there are to this idea. So far I can see some advantages in your proposal compared to the ideas I have otherwise considered. Do you by any chance know if there is an RFC documenting the format of the packets? -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From mancha1 at zoho.com Thu May 28 08:02:40 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 27 May 2015 22:02:40 +0000 Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group In-Reply-To: <87siahhgom.fsf@alice.fifthhorseman.net> References: <48704.1432669189@eng-mail01.juniper.net> <87siahhgom.fsf@alice.fifthhorseman.net> Message-ID: <20150527220240.GA5826@zoho.com> On Wed, May 27, 2015 at 05:08:25PM -0400, Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote: > > Hi Folks, > > > > The generator value of 5 does not lead to a q-ordered subgroup which > > is needed to pass tests in > > > > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf > > I pulled revision 2 of this document from here: > > https://dx.doi.org/10.6028/nist.sp.800-56ar2 > > The "FFC Domain Parameter Generation" section does say: > > g is a generator of the cyclic subgroup of GF(p)* of order q, > > But i don't see a recommendation of why this matters. Surely we don't > want the subgroup of order 2, but what is wrong with using a subgroup > of order 2q = p-1? > > There's clearly no strong security advantage to the 2q subgroup -- > it's just one bit larger -- but is there an attack that works against > the 2q subgroup that doesn't work against the q subgroup? If this is > a known concern, i'd be happy with just a pointer to a paper or web > page explaining the risks of the larger group. > > otoh, if the goal is just to ensure we have word-for-word compliance > with SP800-56A, then it's clear that choosing a different generator is > the way to go (and without much of a security cost). but i'd like to > know if there's a reason other than blind-spec-compliance. Pointers? > > Regards, > > --dkg One reason the generator of the full (Z/pZ)* is avoided is because knowledge of g^a and g^b (both known to Mallory) leaks information about the shared secret g^(ab) via their legendre symbols. This is particularly troublesome in the context of El Gamal. I don't have a reference to recommend off-hand but you might want to google for "decisional diffie hellman assumption". --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kasperd at fzcpf.25.may.2015.kasperd.net Thu May 28 08:03:17 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Thu, 28 May 2015 00:03:17 +0200 Subject: Name based SSH proxy In-Reply-To: <20150527213854.GA3486@colin.search.kasperd.net> References: <20150523124206.GA3538@colin.search.kasperd.net> <20150525073927.GA3492@colin.search.kasperd.net> <87pp5njeyl.fsf@alice.fifthhorseman.net> <20150526214240.GA3469@colin.search.kasperd.net> <556504FF.6020105@gmail.com> <20150527074039.GA3481@colin.search.kasperd.net> <55662C1E.9020902@gmail.com> <20150527213854.GA3486@colin.search.kasperd.net> Message-ID: <20150527220317.GA3624@colin.search.kasperd.net> On 27/05/15 23.38, Kasper Dupont wrote: > On 27/05/15 22.42, ?ngel Gonz?lez wrote: > > Would you consider acceptable for the proxy to send an udp packet to the > > target server > > (eg. udp 514) informing it of the requested hostname it's forwarding? > > That's not a bad idea. It's an idea I hadn't thought about > before, but now I will. I'll have to think about what > advantages and disadvantages there are to this idea. So far > I can see some advantages in your proposal compared to the > ideas I have otherwise considered. > > Do you by any chance know if there is an RFC documenting the > format of the packets? I looked at http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml For some reason it did not list any RFC for UDP port 514. But after a bit more search I found RFC 5424 and 5426. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From dkg at fifthhorseman.net Thu May 28 09:28:09 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 May 2015 19:28:09 -0400 Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group In-Reply-To: <20150527220240.GA5826@zoho.com> References: <48704.1432669189@eng-mail01.juniper.net> <87siahhgom.fsf@alice.fifthhorseman.net> <20150527220240.GA5826@zoho.com> Message-ID: <87617dha7q.fsf@alice.fifthhorseman.net> On Wed 2015-05-27 18:02:40 -0400, mancha wrote: > One reason the generator of the full (Z/pZ)* is avoided is because > knowledge of g^a and g^b (both known to Mallory) leaks information about > the shared secret g^(ab) via their legendre symbols. Their Legendre symbol of g^(ab) is 1 bit; but the full |2q| group is 1 bit larger than the |q| subgroup. Either way, we're not talking about a radical change in cryptographic strength, right? Or is there some way to parlay knowledge of the Legendre symbol of g^(ab) into a larger attack? --dkg From dtucker at zip.com.au Thu May 28 10:14:07 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 28 May 2015 10:14:07 +1000 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> Message-ID: On Sun, May 24, 2015 at 9:20 AM, Darren Tucker wrote: > [...] > The other possible action that IMO would be reasonable but is not listed: > remove all of the 1kbit and 1.5kbit groups > After some consideration we have decided to remove[1] the 1k bit groups from the moduli file. Vendors may want to consider doing this even for older versions of OpenSSH (either by importing the new file, or by removing them from the existing file) as it will result in stronger groups being used for diffie-hellman-group-exchange-sha{1,256} transparently even if the client prefers 1k bit groups (eg PuTTY and derivatives when using 128bit ciphers). [1] https://anongit.mindrot.org/openssh.git/commit/?id=5ab7d5fa03ad55bc438fab45dfb3aeb30a3c237a -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dwm37 at cam.ac.uk Fri May 29 00:14:02 2015 From: dwm37 at cam.ac.uk (David McBride) Date: Thu, 28 May 2015 15:14:02 +0100 Subject: Weak DH primes and openssh In-Reply-To: References: <555F3D93.7050307@cam.ac.uk> Message-ID: <556722AA.8050106@cam.ac.uk> On 27/05/15 10:58, Darren Tucker wrote: > diffie-hellman-group-exchange-sha256 and diffie-hellman-group-exchange-sha1 > use the same message type defined in RFC4419 to request a group, and PuTTY > up to 0.64 uses the same deprecated message type (30) for both. > > See >> https://anongit.mindrot.org/openssh.git/commit/?id=318be28cda1fd9108f2e6f2f86b0b7589ba2aed0 >> >> + if ((datafellows & SSH_OLD_DHGEX) != 0) { >> + p = filter_proposal(p, "diffie-hellman-group-exchange-sha256"); >> + p = filter_proposal(p, "diffie-hellman-group-exchange-sha1"); >> + } >> > The removal of the pre-RFC4419 message type in OpenSSH was made after the > last release. Please retry your test with a current development snapshot. Ouch. Thank you very much for chasing this down; while I haven't compiled up a current development OpenSSH snapshot and re-run my previous experiment, I assume you're correct. Digging through the PuTTY git repository, the corresponding update that adds SSH_MSG_KEX_DH_GEX_REQUEST (as opposed to _REQUEST_OLD) support is here: http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commit;h=62a1bce7cb3ecb98feb57c7f1fd5d55845ce1533 ... and so should become available in the next PuTTY release, along with elliptic-curve key-exchange and host key support. The pragmatic consequence is that I should not disable both -group1-sha1 and -group14-sha1 key-exchange support on my servers, nor suggest others to do the same, as this configuration will break compatibility with current versions of PuTTY when the configuration is inherited by future versions of OpenSSH. (As you might expect, PuTTY is quite widely used within Cambridge. Also, judging from some of the screenshots of other Windows SSH/SFTP software, it appears that a fair amount of the PuTTY codebase can be found in other tools as well.) Pragmatically, the conclusion I've reached is that, while it would involve violating an RFC MUST, disabling -group1-sha1 while leaving -group14-sha1 support enabled should not significantly affect interoperability, and would address concerns that users with antiquated or misconfigured SSH clients would reveal sensitive data to state-level passive observers. I am conscious that I am not an expert, so please do correct me if any of this appears to be wrong or foolish. Would it be virtuous to postpone the application of the SSH_OLD_DHGEX commit you reference above until after the new version of PuTTY has been released and has time to enter circulation? Kind regards, David -- David McBride Unix Specialist, University Information Services From hkario at redhat.com Fri May 29 00:54:21 2015 From: hkario at redhat.com (Hubert Kario) Date: Thu, 28 May 2015 16:54:21 +0200 Subject: Weak DH primes and openssh In-Reply-To: <87pp5mhrn4.fsf@alice.fifthhorseman.net> References: <555DDD09.3090606@debian.org> <10094608.Ne5zRi2mUz@pintsize.usersys.redhat.com> <87pp5mhrn4.fsf@alice.fifthhorseman.net> Message-ID: <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> On Wednesday 27 May 2015 13:11:43 Daniel Kahn Gillmor wrote: > On Wed 2015-05-27 05:23:41 -0400, Hubert Kario wrote: > > Hmm, I have a distinct recollection of reading of a possibility of a > > small subgroup attacks on primes (as in very few primes have this > > property, so randomly selected one are almost certainly not > > problematic, but if you can pick any prime, you can find them) > > > > Maybe what they mean is that this may does not apply to Sophie Germain > > primes, but to "DSA style" primes, I haven't dug too deep into > > this. Creating it pseudo-randomly from nothing up my sleeve numbers > > fixes this issue anyway. > > I think you mean "safe primes" where you say "Sophie Germain primes" -- > if q = (p-1)/2, and p and q are primes, then p is a "safe prime" and q > is a "Sophie Germain prime". yes, I used it as a synonym for "safe prime" > Small subgroup attacks are not possible for safe primes as long as you > test your peer's public share and the generator to ensure that they are > in the range (exclusive) 1 < x < p-1. > > This is because totient(p) = p-1 (because p is prime), and p-1 has only > two factors: 2 and q. So there exists one small subgroup, but it's of > order 2, and its generator is p-1 (the subgroup cycles between p-1 and > 1). All other elements are generators of order either q or p-1. There > are no other subgroups, iiuc. yes, this does sound right > If this is the only attack you're trying to address, and you've already > limited yourself to safe primes, then NUMS properties don't really add > anything. The NUMS approach is there are to try to avoid the > possibility of other, unknown cryptanalytic attacks against some > infrequent type of group, so that the entity who defines the group can't > force you into this secret corner case if they have special knowledge. that being said, how using NUMS seeds to generate safe prime would hurt? also, doesn't that require us to provide primality certificates for q rather than p? -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri May 29 03:12:15 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 May 2015 13:12:15 -0400 Subject: Weak DH primes and openssh In-Reply-To: <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> References: <555DDD09.3090606@debian.org> <10094608.Ne5zRi2mUz@pintsize.usersys.redhat.com> <87pp5mhrn4.fsf@alice.fifthhorseman.net> <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> Message-ID: <87siagd3tc.fsf@alice.fifthhorseman.net> On Thu 2015-05-28 10:54:21 -0400, Hubert Kario wrote: > that being said, how using NUMS seeds to generate safe prime would hurt? I don't see how it would hurt, but i'm just pointing out that i don't think it provides any additional defense against small subgroup attacks once you've settled on requiring safe primes. Of course, if you use some sort of NUMS process then you have to verify that the NUMS process was followed as well, which adds an additional chunk of work for anyone who is trying to do corroboration. > also, doesn't that require us to provide primality certificates for q rather > than p? Yes, if we expect to use safe primes, i think we need primality proofs for both p and q. For the new TLS FFDHE groups, i've posted those here: https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ (i'm not recommending using the same groups for TLS and SSH, fwiw. splitting the potential attack surface by application type seems like a good thing; it adds no additional fingerprinting/metadata, because the protocols themselves are already fingerprintable) I guess i'd summarize the situation as: * NUMS requires extra work for both people who choose the moduli, and for corroborators (moduli.c's gen_candidates starts from BN_rand on line 328, so we're not even claiming to use NUMS in the current method) * primality proofs require a significant amount of extra work for people who choose the moduli, and some extra work for corroborators (verification at least) * even basic random M-R checks (which wouldn't defend against an attacker who knows how to generate strong pseudoprimes) require work from corroborators * we haven't had much public corroboration of the moduli shipped by default in the past (or if we have, i've missed it) * it's not fair to Darren and Damien that they should be single points of failure here. Any thoughts on things that we might be able to improve? --dkg From mancha1 at zoho.com Fri May 29 04:31:27 2015 From: mancha1 at zoho.com (mancha) Date: Thu, 28 May 2015 18:31:27 +0000 Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group In-Reply-To: <87617dha7q.fsf@alice.fifthhorseman.net> References: <48704.1432669189@eng-mail01.juniper.net> <87siahhgom.fsf@alice.fifthhorseman.net> <20150527220240.GA5826@zoho.com> <87617dha7q.fsf@alice.fifthhorseman.net> Message-ID: <20150528183127.GA2336@zoho.com> On Wed, May 27, 2015 at 07:28:09PM -0400, Daniel Kahn Gillmor wrote: > On Wed 2015-05-27 18:02:40 -0400, mancha wrote: > > One reason the generator of the full (Z/pZ)* is avoided is because > > knowledge of g^a and g^b (both known to Mallory) leaks information > > about the shared secret g^(ab) via their legendre symbols. > > Their Legendre symbol of g^(ab) is 1 bit; but the full |2q| group is 1 > bit larger than the |q| subgroup. Either way, we're not talking about > a radical change in cryptographic strength, right? Or is there some > way to parlay knowledge of the Legendre symbol of g^(ab) into a larger > attack? Your intuition is correct. Using a generator of the full (Z/pZ)* is of more concern for El Gamal because of the compromised semantic security (being able to derive the cleartext's Legendre symbol can be potentially very bad). I brought it up in this thread to offer a possible explanation for the NIST recommendations you were discussing. That said, we should be much more concerned that p be a "safe prime" so we're assured the g we end up using generates a large group (order q or 2q assuming we don't pick g=1 or g=p-1). On Mark's report, g=5 indeed generates the full (Z/pZ)* for the prime(*) initially recommended in bug 2302's fix. But, that's no different from generators in the full moduli file. My quick test shows all 274 generate the associated full groups. That's moot now because the fallback is a 4096-bit prime taken from RFC 3526 [1]. According to my tests, that p is a safe prime(**) and the recommended generator g=2 generates the subgroup order q. --mancha [1] https://tools.ietf.org/html/rfc3526#page-5 (*) Certified with PRIMO: https://tinyurl.com/nrqrrcg (**) Certified with PRIMO: https://tinyurl.com/nwvezog & https://tinyurl.com/o2cxju7 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mike at sentex.net Fri May 29 06:49:45 2015 From: mike at sentex.net (Mike Tancsa) Date: Thu, 28 May 2015 16:49:45 -0400 Subject: HostKeyAgent from hardware Message-ID: <55677F69.4050500@sentex.net> I have been exploring generating a host's RSA key from a PKCS#15 token. I got it to work with an old SafeNet/Aladdin eToken (non java version) using OpenCT and OpenSC on FreeBSD. (The steps I used at http://www.tancsa.com/mdtblog/?p=73). Apart from this increasingly hard to get bit of hardware, what other hardware devices are people using to access ssh host keys in where necessary with OpenSSH in the *BSD or Linux world ? Hopefully devices that have quantities of < 50 available, and I dont have to be a country to buy them ? Or do people just look for servers that have TPMs integrated into them ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From keisial at gmail.com Fri May 29 06:57:38 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 28 May 2015 22:57:38 +0200 Subject: Weak DH primes and openssh In-Reply-To: <20150527025539.GA13936@zoho.com> References: <555DDD09.3090606@debian.org> <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com> <87lhgbkzf2.fsf@alice.fifthhorseman.net> <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com> <87y4kbjgty.fsf@alice.fifthhorseman.net> <20150527025539.GA13936@zoho.com> Message-ID: <55678142.9070605@gmail.com> On 27/05/15 04:55, mancha wrote: > As I write this I've checked through #209. Those with spare CPU cycles > on 64-bit Linux can help with the 65 strong pseudoprimes remaining > (#210 to #274). > > Those who wish to help should get PRIMO [1] and grab the full set of > input files I made: > > http://sf.net/projects/mancha/files/misc/openssh-moduli-20150522_primo.tar.bz2 > > The 7680-bit moduli (#225 - #248) and 8192-bit moduli (#249 - #274) are > up for grabs. Probably best if you claim your range to avoid effort > duplication. /me claims 237 - 248 From dkg at fifthhorseman.net Fri May 29 08:23:50 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 May 2015 18:23:50 -0400 Subject: HostKeyAgent from hardware In-Reply-To: <55677F69.4050500@sentex.net> References: <55677F69.4050500@sentex.net> Message-ID: <87d21kbatl.fsf@alice.fifthhorseman.net> On Thu 2015-05-28 16:49:45 -0400, Mike Tancsa wrote: > I have been exploring generating a host's RSA key from a PKCS#15 token. > I got it to work with an old SafeNet/Aladdin eToken (non java version) > using OpenCT and OpenSC on FreeBSD. (The steps I used at > http://www.tancsa.com/mdtblog/?p=73). My guess is that these devices would be too slow for use on the public internet -- i've seen many of them take > 1 second for a 2048-bit RSA secret key operation. Since the server has to sign part of the handshake relatively early (before the client is authenticated), an attacker could tie up the token just by starting a handshake and forcing the signature, i think. This would make your server trivially easy to DoS at a very low bandwidth, no? I haven't tried the attack myself. > Apart from this increasingly hard to get bit of hardware, what other > hardware devices are people using to access ssh host keys in where > necessary with OpenSSH in the *BSD or Linux world ? Hopefully devices > that have quantities of < 50 available, and I dont have to be a country > to buy them ? Or do people just look for servers that have TPMs > integrated into them ? I'd be curious to hear other answers to this too. --dkg From djm at mindrot.org Fri May 29 09:23:59 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 May 2015 09:23:59 +1000 (AEST) Subject: Weak DH primes and openssh In-Reply-To: <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> References: <555DDD09.3090606@debian.org> <10094608.Ne5zRi2mUz@pintsize.usersys.redhat.com> <87pp5mhrn4.fsf@alice.fifthhorseman.net> <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> Message-ID: On Thu, 28 May 2015, Hubert Kario wrote: > > If this is the only attack you're trying to address, and you've > > already limited yourself to safe primes, then NUMS properties don't > > really add anything. The NUMS approach is there are to try to avoid > > the possibility of other, unknown cryptanalytic attacks against some > > infrequent type of group, so that the entity who defines the group > > can't force you into this secret corner case if they have special > > knowledge. > > that being said, how using NUMS seeds to generate safe prime would > hurt? If you're concerned about precomputation, then it effectively gives the attackers a list of what you're going to use in the future. > also, doesn't that require us to provide primality certificates for q > rather than p? IMO you'd want both to prove a safe prime -d From mdb at juniper.net Fri May 29 11:22:03 2015 From: mdb at juniper.net (Mark D. Baushke) Date: Thu, 28 May 2015 18:22:03 -0700 Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group In-Reply-To: <20150528183127.GA2336@zoho.com> References: <48704.1432669189@eng-mail01.juniper.net> <87siahhgom.fsf@alice.fifthhorseman.net> <20150527220240.GA5826@zoho.com> <87617dha7q.fsf@alice.fifthhorseman.net> <20150528183127.GA2336@zoho.com> Message-ID: <42056.1432862523@eng-mail01.juniper.net> mancha writes: > On Mark's report, g=5 indeed generates the full (Z/pZ)* for the prime(*) > initially recommended in bug 2302's fix. But, that's no different > from generators in the full moduli file. My quick test shows all 274 > generate the associated full groups. Yes, I have observed that most RFC 4419 moduli entries generate full groups. It seems that most of the time the RFC 4419 method of selecting a generator g provides for a full (Z/pZ) for the generated prime p. So, if you are running with random g^x and g^y values, about half of the time you will get a q-ordered subgroup and half of the time you will get one that is in the full group and would need to be failed at runtime if one is trying to enforce the NIST SP 800-56A tests. If there is a need to sell products which use OpenSSH into the public sector (various Governements), then FIPS 140-2 compliance is needed. This means that NIST SP 800-56A validation is important. Generation of a moduli file that complies with RFC 4419 and NIST SP 800-56A is difficult... unless one ignores 'useful technique' provided in RFC 4419 section 6.1 for finding a generator for each moduli entry. So, an alternative 'useful technique' is to see if g=2 is a subgroup or full group generator and use g=2 only when it generates a q-ordered subgroup. It also means that interoperability with other implementations become 'interesting' if a client needs to reject roughly half of the g^y values provided by a non-800-56A compliant server. Of course, in theory the folks that need compliance would not field a box that offered up 'bad' values of g and p... > That's moot now because the fallback is a 4096-bit prime taken from RFC > 3526 [1]. According to my tests, that p is a safe prime(**) and the > recommended generator g=2 generates the subgroup order q. Yes, this is very useful. > --mancha > > [1] https://tools.ietf.org/html/rfc3526#page-5 > > (*) Certified with PRIMO: https://tinyurl.com/nrqrrcg > (**) Certified with PRIMO: https://tinyurl.com/nwvezog & https://tinyurl.com/o2cxju7 -- Mark From djm at mindrot.org Fri May 29 17:12:49 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 May 2015 17:12:49 +1000 (AEST) Subject: Call for testing: OpenSSH 6.9 Message-ID: Hi, OpenSSH 6.9 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs or via Git at https://anongit.mindrot.org/openssh.git/ Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Note, we are going to ship OpenSSH 6.9 with SSH protocol 1 still compiled in by default. OpenSSH 7.0 will deprecate it along with other protocol features (more details about what is planned will be in the final release notes). New Features ------------ * ssh(1), sshd(8): promote chacha20-poly1305 at openssh.com to be the default cipher * sshd(8): support admin-specified arguments to AuthorizedKeysCommand; bz#2081 * sshd(8): add AuthorizedPrincipalsCommand that allows retrieving authorized principals information from a subprocess rather than a file. * ssh(1), ssh-add(1): support PKCS#11 devices with external PIN entry devices bz#2240 * sshd(8): allow GSSAPI host credential check to be relaxed for multihomed hosts via GSSAPIStrictAcceptorCheck option; bz#928 * ssh-keygen(1): support "ssh-keygen -lF hostname" to search known_hosts and print key hashes rather than full keys. * ssh-agent(1): add -D flag to leave ssh-agent in foreground without enabling debug mode; bz#2381 Bugfixes -------- * ssh(1), sshd(8): deprecate legacy SSH2_MSG_KEX_DH_GEX_REQUEST_OLD message and do not try to use it against some 3rd-party SSH implementations that use it (older PuTTY, WinSCP). * Many fixes for problems caused by compile-time deactivation of SSH1 support (including bz#2369) * ssh(1), sshd(8): cap DH-GEX group size at 4Kbits for Cisco implementations as some would fail when attempting to use group sizes >4K; bz#2209 * ssh(1): fix out-of-bound read in EscapeChar configuration option parsing; bz#2396 * sshd(8): fix application of PermitTunnel, LoginGraceTime, AuthenticationMethods and StreamLocalBindMask options in Match blocks * ssh(1), sshd(8): improve disconnection message on TCP reset; bz#2257 * ssh(1): remove failed remote forwards established by muliplexing from the list of active forwards; bz#2363 * sshd(8): make parsing of authorized_keys "environment=" options independent of PermitUserEnv being enabled; bz#2329 * sshd(8): fix post-auth crash with permitopen=none; bz#2355 * ssh(1), ssh-add(1), ssh-keygen(1): allow new-format private keys to be encrypted with AEAD ciphers; bz#2366 * ssh(1): allow ListenAddress, Port and AddressFamily configuration options to appear in any order; bz#68 * sshd(8): check for and reject missing arguments for VersionAddendum and ForceCommand; bz#2281 * ssh(1), sshd(8): don't treat unknown certificate extensions as fatal; bz#2387 * ssh-keygen(1): make stdout and stderr output consistent; bz#2325 * ssh(1): mention missing DISPLAY environment in debug log when X11 forwarding requested; bz#1682 * sshd(8): correctly record login when UseLogin is set; bz#378 * sshd(8): Add some missing options to sshd -T output and fix output of VersionAddendum and HostCertificate. bz#2346 * Document and improve consistency of options that accept a "none" argument" TrustedUserCAKeys, RevokedKeys (bz#2382), AuthorizedPrincipalsFile (bz#2288) * ssh(1): include remote username in debug output; bz#2368 * sshd(8): avoid compatibility problem with some versions of Tera Term, which would crash when they received the hostkeys notification message (hostkeys-00 at openssh.com) * sshd(8): mention ssh-keygen -E as useful when comparing legacy MD5 host key fingerprints; bz#2332 * ssh(1): clarify pseudo-terminal request behaviour and use make manual language consistent; bz#1716 * ssh(1): document that the TERM environment variable is not subject to SendEnv and AcceptEnv; bz#2386 Portable OpenSSH ---------------- * sshd(8): Format UsePAM setting when using sshd -T, part of bz#2346 * Look for '${host}-ar' before 'ar', making cross-compilation easier; bz#2352. * Several portable compilation fixes: bz#2402, bz#2337, bz#2370 * moduli(5): update DH-GEX moduli OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From hkario at redhat.com Fri May 29 20:26:42 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 29 May 2015 12:26:42 +0200 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> Message-ID: <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com> On Friday 29 May 2015 09:23:59 Damien Miller wrote: > On Thu, 28 May 2015, Hubert Kario wrote: > > > If this is the only attack you're trying to address, and you've > > > already limited yourself to safe primes, then NUMS properties don't > > > really add anything. The NUMS approach is there are to try to avoid > > > the possibility of other, unknown cryptanalytic attacks against some > > > infrequent type of group, so that the entity who defines the group > > > can't force you into this secret corner case if they have special > > > knowledge. > > > > that being said, how using NUMS seeds to generate safe prime would > > hurt? > > If you're concerned about precomputation, I'm afraid for precomputation only in 1024 bit case, /which we should strive not to use anyway/ > then it effectively gives the > attackers a list of what you're going to use in the future. Not really, no. We can use this time an initial seed of "OpenSSH 1024 bit prime, attempt #1". Next time we generate the primes we can use the initial seed of "2017 OpenSSH 1024 bit prime, attempt #1", but we can use just as well a "2nd generation OpenSSH 1024 bit DH parameters, try number 1". Then we can also change the algorithm to use this seed for M-R witnesses, or not. Then we can use SHA-512 instead of SHA-256, or some SHA-3 variant. The space for possible selected values is rather large... > > also, doesn't that require us to provide primality certificates for q > > rather than p? > > IMO you'd want both to prove a safe prime The process to prove primality of p when you know that q is prime[1] is rather simple, just use Pocklington Theorem to do that. So the primality of q is basically a primality certificate for p. 1 - continuing the nomenclature of q = (p-1)/2, where p and q are prime -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From djm at mindrot.org Sat May 30 00:09:47 2015 From: djm at mindrot.org (Damien Miller) Date: Sat, 30 May 2015 00:09:47 +1000 (AEST) Subject: Weak DH primes and openssh In-Reply-To: <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com> References: <555DDD09.3090606@debian.org> <3876853.EFE75GIvVm@pintsize.usersys.redhat.com> <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com> Message-ID: On Fri, 29 May 2015, Hubert Kario wrote: > Not really, no. > > We can use this time an initial seed of "OpenSSH 1024 bit prime, attempt #1". > Next time we generate the primes we can use the initial seed of "2017 OpenSSH > 1024 bit prime, attempt #1", but we can use just as well a "2nd generation > OpenSSH 1024 bit DH parameters, try number 1". Then we can also change the > algorithm to use this seed for M-R witnesses, or not. Then we can use SHA-512 > instead of SHA-256, or some SHA-3 variant. If you're constantly changing the parameters, then this is the opposite of NUMS. Anyway, I don't think a NUMS-like approach is necessary. It certainly isn't with users independently generating primality certificates. -d From hkario at redhat.com Sat May 30 00:14:45 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 29 May 2015 16:14:45 +0200 Subject: Weak DH primes and openssh In-Reply-To: References: <555DDD09.3090606@debian.org> <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com> Message-ID: <1620119.MSLpl5Hm2D@pintsize.usersys.redhat.com> On Saturday 30 May 2015 00:09:47 Damien Miller wrote: > On Fri, 29 May 2015, Hubert Kario wrote: > > Not really, no. > > > > We can use this time an initial seed of "OpenSSH 1024 bit prime, attempt > > #1". Next time we generate the primes we can use the initial seed of > > "2017 OpenSSH 1024 bit prime, attempt #1", but we can use just as well a > > "2nd generation OpenSSH 1024 bit DH parameters, try number 1". Then we > > can also change the algorithm to use this seed for M-R witnesses, or not. > > Then we can use SHA-512 instead of SHA-256, or some SHA-3 variant. > > If you're constantly changing the parameters, then this is the opposite of > NUMS. Anyway, I don't think a NUMS-like approach is necessary. It certainly > isn't with users independently generating primality certificates. yes, I'm not saying that we should regenerate them constantly, I'm just saying that if the decision was ever to do that again, it's basically impossible to predict now what those numbers will be -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From kasperd at kdxdx.23.may.2015.kasperd.net Sat May 30 22:00:24 2015 From: kasperd at kdxdx.23.may.2015.kasperd.net (Kasper Dupont) Date: Sat, 30 May 2015 14:00:24 +0200 Subject: Using two agents Message-ID: <20150530120023.GA3477@colin.search.kasperd.net> As far as I can tell when the ssh command uses an agent to authenticate to a server and then forwards an agent to that server, it will always use the same agent for both purposes. Has there been any attempt to make it possible for the ssh command to use two different agents, such that I can use one agent to authenticate and then forward a different agent to the server? -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From nkadel at gmail.com Sat May 30 22:34:21 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 30 May 2015 08:34:21 -0400 Subject: Using two agents In-Reply-To: <20150530120023.GA3477@colin.search.kasperd.net> References: <20150530120023.GA3477@colin.search.kasperd.net> Message-ID: On Sat, May 30, 2015 at 8:00 AM, Kasper Dupont wrote: > As far as I can tell when the ssh command uses an agent to > authenticate to a server and then forwards an agent to that > server, it will always use the same agent for both purposes. > > Has there been any attempt to make it possible for the ssh > command to use two different agents, such that I can use one > agent to authenticate and then forward a different agent to > the server? That sounds really, really awkward, and would create a real "provenance" problem for the agent being accessed on the other side. What problem are you actually trying to solve? From kasperd at fzcpf.25.may.2015.kasperd.net Sat May 30 23:00:10 2015 From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont) Date: Sat, 30 May 2015 15:00:10 +0200 Subject: Using two agents In-Reply-To: References: <20150530120023.GA3477@colin.search.kasperd.net> Message-ID: <20150530130010.GA3422@colin.search.kasperd.net> On 30/05/15 08.34, Nico Kadel-Garcia wrote: > On Sat, May 30, 2015 at 8:00 AM, Kasper Dupont > wrote: > > As far as I can tell when the ssh command uses an agent to > > authenticate to a server and then forwards an agent to that > > server, it will always use the same agent for both purposes. > > > > Has there been any attempt to make it possible for the ssh > > command to use two different agents, such that I can use one > > agent to authenticate and then forward a different agent to > > the server? > > That sounds really, really awkward, and would create a real > "provenance" problem for the agent being accessed on the other side. This couldn't possibly be a problem for the other side, the other side will only ever know about one agent. > > What problem are you actually trying to solve? On my laptop I have key1 and key2. I can use key1 to log in on server1, and I can use key2 to log in on server2. I want neither key to leave the laptop, and only key2 is allowed to be forwarded to other hosts. I need to ssh to server1 and on server1 run an scp command to exchange files with server2. This approach works as long as key1 is not encrypted: ssh-agent bash ssh-add key2 ssh -i key1 -A server1 But if key1 is encrypted it is highly inconvenient to have to type my password each time I connect to server1. It is also prone to phishing attacks, because when I type the ssh command, how can I really know if the password prompt I see is from ssh needing to decrypt key1 or from server1 trying to get my decryption password. Starting two agents locally and loading key1 and key2 into separate agents is trivial. Storing the name of the socket for the first agent in a secondary environment variable before starting the second agent (and overwriting SSH_AUTH_SOCK) is also trivial. But now that I have two enviroment variables pointing to the two agents, I can't ask ssh to use the first agent to log me in on server1 and forward the other agent. Because ssh will use SSH_AUTH_SOCK for both purposes. It is surely possible to update the ssh command to support the use of two separate agents (for example by allowing the paths to the two sockets to be specified in two configuration options). I just want to know if anybody did this already, so I don't waste my time reinventing the wheel. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6); From phil.pennock at globnix.org Sun May 31 00:38:06 2015 From: phil.pennock at globnix.org (Phil Pennock) Date: Sat, 30 May 2015 14:38:06 +0000 Subject: Using two agents In-Reply-To: <20150530130010.GA3422@colin.search.kasperd.net> References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> Message-ID: <20150530143806.GA274@tower.spodhuis.org> On 2015-05-30 at 15:00 +0200, Kasper Dupont wrote: > On my laptop I have key1 and key2. I can use key1 to log in > on server1, and I can use key2 to log in on server2. I want > neither key to leave the laptop, and only key2 is allowed > to be forwarded to other hosts. As validation for what Kasper is saying, so that others know that it's not just him: $work would use the feature you describe. At present, the key1 that you describe is unencrypted :( but is used for perimeter access, while key2 is used for intra-cluster access, but because it's forwarded onto less trusted hosts, can't be allowed to be used for getting into the cluster in the first place -- we constrain the impact of a breach. Not ideal. We'd like to move to using transient certificates issued for perimeter access, using OpenSSH CA, but that requires that the key1 role be loaded from an agent. If we move to the same transient certificate used for the key2 role then we get all the benefits of short-lived proof, but we lose our containment of impact of breach. So if you come up with a solution letting the ssh(1) command be told to use one agent for auth to the remote host but to pass a different agent as the forwarded auth signer, we would use it too. -Phil From nkadel at gmail.com Sun May 31 01:26:22 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 30 May 2015 11:26:22 -0400 Subject: Using two agents In-Reply-To: References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> Message-ID: On Sat, May 30, 2015 at 11:25 AM, Nico Kadel-Garcia wrote: > Mind you, I've never been complete thrilled with ssh-agent. If you > really want to segregate credentials for different environments, you > might look into Kerberos based authentication, which can provide a > very different approach to finer grained credential management. I just > wish I could get it to work with Subversion..... Sorry, should have said 'svn+ssh'. From nkadel at gmail.com Sun May 31 01:25:13 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 30 May 2015 11:25:13 -0400 Subject: Using two agents In-Reply-To: <20150530143806.GA274@tower.spodhuis.org> References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> Message-ID: On Sat, May 30, 2015 at 10:38 AM, Phil Pennock wrote: > On 2015-05-30 at 15:00 +0200, Kasper Dupont wrote: >> On my laptop I have key1 and key2. I can use key1 to log in >> on server1, and I can use key2 to log in on server2. I want >> neither key to leave the laptop, and only key2 is allowed >> to be forwarded to other hosts. > > As validation for what Kasper is saying, so that others know that it's > not just him: > > $work would use the feature you describe. At present, the key1 that you > describe is unencrypted :( but is used for perimeter access, while key2 > is used for intra-cluster access, but because it's forwarded onto less > trusted hosts, can't be allowed to be used for getting into the cluster > in the first place -- we constrain the impact of a breach. Not ideal. > > We'd like to move to using transient certificates issued for perimeter > access, using OpenSSH CA, but that requires that the key1 role be loaded > from an agent. If we move to the same transient certificate used for > the key2 role then we get all the benefits of short-lived proof, but we > lose our containment of impact of breach. > > So if you come up with a solution letting the ssh(1) command be told to > use one agent for auth to the remote host but to pass a different agent > as the forwarded auth signer, we would use it too. The workable, but fugly solution is to load an ssh-agent with the keys you want in environment two, keep a local unencrypted private key for permiter access to environment one stored in a shielded, protected, ideally locally disk partition encrypted location, and set up $HOME/.ssh/config with a "Host" entry to specify that non-standard-location unencrypted key location to use for accessing that permiter host or those perimeter hosts. I don't like this solution myself, but it satisfies all the stated requirements of "I don't want to keep typing my perimeter key passphrase" I'll also point out that with Gnome and KDE there are wallets to hold keys and to unlock them once in the wallet that might be useful. Another workaround is to set an ssh-agent with both keys and automatically delete that first key, if present, in your .bashrc or .login procedures in the remote account. That doesn't keep the first private key around for repeated logins, but that might be enough for some circumstances. Mind you, I've never been complete thrilled with ssh-agent. If you really want to segregate credentials for different environments, you might look into Kerberos based authentication, which can provide a very different approach to finer grained credential management. I just wish I could get it to work with Subversion..... From kevin.brott at gmail.com Sun May 31 02:30:11 2015 From: kevin.brott at gmail.com (Kevin Brott) Date: Sat, 30 May 2015 09:30:11 -0700 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: Message-ID: <5569E593.6050708@gmail.com> Starting building/testing for the lab systems I have Monday. Any chance a fix for Bug 2404 could get wedged in before release? -- # include /* Kevin Brott */ From ronf at timeheart.net Sun May 31 03:37:38 2015 From: ronf at timeheart.net (Ron Frederick) Date: Sat, 30 May 2015 10:37:38 -0700 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: Message-ID: <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net> On May 29, 2015, at 12:12 AM, Damien Miller wrote: > OpenSSH 6.9 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bug fixes. I just compiled and ran the tests for openssl-snap-20150531 on Linux (Ubuntu 14.04.2 LTS) and MacOS (10.10.3). On Linux, the code compiled cleanly. However, during ?make tests? I got the following error a number of times: WARNING: /usr/local/etc/moduli does not exist, using fixed modulus Later in the test sequence I got the error: run test connect.sh ... Missing privilege separation directory: /var/empty FATAL: sshd_proxy broken make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/tmp/openssh/regress' make: *** [tests] Error 2 make tests 153.92s user 4.68s system 98% cpu 2:41.52 total I was not running as root at the time, as I wasn?t intending to install this version. It looks like it assumes that /var/empty will already exist, though, which it doesn?t on my system. The currently installed sshd does have UsePrivilegeSeparation enabled, and it looks like the sshd user is set up with have /var/run/sshd as its home directory on this system, but the test script didn?t pick that up. On MacOS, the code compiled, but there were a large number of warnings about constructs that were deprecated back in OS X 10.7. The output is quite large, but I?d be happy to provide it to anyone who wants it. Here?s an example of the first warning: gcc -g -O2 -Qunused-arguments -Wunknown-warning-option -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE -I. -I. -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c ssh_api.c -o ssh_api.o ssh_api.c:85:3: warning: 'OPENSSL_add_all_algorithms_noconf' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations] OpenSSL_add_all_algorithms(); ^ /usr/include/openssl/evp.h:829:3: note: expanded from macro 'OpenSSL_add_all_algorithms' OPENSSL_add_all_algorithms_noconf() ^ /usr/include/openssl/evp.h:821:6: note: 'OPENSSL_add_all_algorithms_noconf' has been explicitly marked deprecated here void OPENSSL_add_all_algorithms_noconf(void) DEPRECATED_IN_MAC_OS_X_VERS... ^ 1 warning generated. Other than these warnings, the code did compile on MacOS and successfully passed all the tests. I can also confirm that this version fixes bz#2366, as noted in the change log. -- Ron Frederick ronf at timeheart.net From peter at stuge.se Sun May 31 04:41:33 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 30 May 2015 20:41:33 +0200 Subject: Using two agents In-Reply-To: References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> Message-ID: <20150530184134.32429.qmail@stuge.se> Nico Kadel-Garcia wrote: > Mind you, I've never been complete thrilled with ssh-agent. Then look into extending it, or writing a new one which does what you want. > If you really want to segregate credentials for different environments The agent knows who is asking it about using a key, so you could certainly have a single agent which applies a policy based on that. //Peter From kevin.brott at gmail.com Sun May 31 04:56:07 2015 From: kevin.brott at gmail.com (Kevin Brott) Date: Sat, 30 May 2015 11:56:07 -0700 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: <5569E593.6050708@gmail.com> References: <5569E593.6050708@gmail.com> Message-ID: Debian GNU/Linux 8.0 (jessie) OpenSSL 1.0.1k gcc (Debian 4.9.2-10) 4.9.2 "make tests" fails here: /usr/src/INET/openssh/ssh-keygen -lf /usr/src/INET/openssh/regress//t12.out.pub | grep test-comment-1234 >/dev/null run test connect.sh ... ssh connect with protocol 1 failed ssh connect with protocol 2 failed failed simple connect Makefile:192: recipe for target 't-exec' failed make[1]: *** [t-exec] Error 1 make[1]: Leaving directory '/usr/src/INET/openssh/regress' Makefile:544: recipe for target 'tests' failed make: *** [tests] Error 2 ?failed-ssh.log ends with: debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey debug3: authmethod_lookup publickey debug3: remaining preferred: debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /usr/src/INET/openssh/regress/rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98 debug3: sign_and_send_pubkey: RSA SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98 debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,password,keyboard-interactive). FAIL: ssh connect with protocol 2 failed ? ?failed-sshd.log ends with: debug2: input_userauth_request: try method publickey [preauth] debug3: mm_key_allowed entering [preauth] debug3: mm_request_send entering: type 22 [preauth] debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] debug3: mm_request_receive_expect entering: type 23 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 22 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7f0b6f1499d0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /usr/src/INET/openssh/regress/authorized_keys_root debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /usr/src/INET/openssh/regress/authorized_keys_root, line 1 RSA SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7f0b6f1499d0 is allowed debug3: mm_request_send entering: type 23 debug3: mm_key_verify entering [preauth] debug3: mm_request_send entering: type 24 [preauth] debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth] debug3: mm_request_receive_expect entering: type 25 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 24 debug3: mm_answer_keyverify: key 0x7f0b6f149c30 signature verified debug3: mm_request_send entering: type 25 ROOT LOGIN REFUSED FROM 127.0.0.1 Failed publickey for root from 127.0.0.1 port 36951 ssh2: RSA SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98 debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa [preauth] ROOT LOGIN REFUSED FROM 127.0.0.1 [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] FAIL: ssh connect with protocol 2 failed Connection closed by 127.0.0.1 [preauth] debug1: do_cleanup [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive entering debug1: do_cleanup debug1: Killing privsep child 25262 On Sat, May 30, 2015 at 9:30 AM, Kevin Brott wrote: > > Starting building/testing for the lab systems I have Monday. > > Any chance a fix for Bug 2404 < > https://bugzilla.mindrot.org/show_bug.cgi?id=2404> could get wedged in > before release? > > -- > # include > /* Kevin Brott */ > > -- # include /* Kevin Brott */ From doctor at doctor.nl2k.ab.ca Sun May 31 07:12:35 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 30 May 2015 15:12:35 -0600 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: <5569E593.6050708@gmail.com> Message-ID: <20150530211235.GA20740@doctor.nl2k.ab.ca> So far BSD/OS and opensh 6.9 pre works with ZOC and Tera Term. Putty and WINSCP are broken. Will test on FreeBSD 10.1 amd64 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism UK! Vote LDem on 7 May 2015!! From keisial at gmail.com Sun May 31 07:37:18 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 30 May 2015 23:37:18 +0200 Subject: Using two agents In-Reply-To: <20150530184134.32429.qmail@stuge.se> References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> <20150530184134.32429.qmail@stuge.se> Message-ID: <556A2D8E.9070802@gmail.com> On 30/05/15 20:41, Peter Stuge wrote: >> If you really want to segregate credentials for different environments > The agent knows who is asking it about using a key, so you could > certainly have a single agent which applies a policy based on that. No, it doesn't. For the ssh-agent, it's the same ssh(1) process both times. The difference lies in that the first time it is using it itself for authentication and the second one it is asking that on behalf of a remote untrusted process. (OTOH the proposal from February that suggested a "received parameter", would allow this kind of thing) From ras at anzio.com Sun May 31 07:38:25 2015 From: ras at anzio.com (Bob Rasmussen) Date: Sat, 30 May 2015 14:38:25 -0700 (PDT) Subject: Call for testing: OpenSSH 6.9 In-Reply-To: <20150530211235.GA20740@doctor.nl2k.ab.ca> References: <5569E593.6050708@gmail.com> <20150530211235.GA20740@doctor.nl2k.ab.ca> Message-ID: Would anyone like to make a 6.9 server available for testing our client (Anzio) against? On Sat, 30 May 2015, The Doctor wrote: > So far BSD/OS and opensh 6.9 pre works with ZOC and Tera Term. > > Putty and WINSCP are broken. > > Will test on FreeBSD 10.1 amd64 > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > UK! Vote LDem on 7 May 2015!! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From keisial at gmail.com Sun May 31 07:42:52 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 30 May 2015 23:42:52 +0200 Subject: Using two agents In-Reply-To: <20150530130010.GA3422@colin.search.kasperd.net> References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> Message-ID: <556A2EDC.9020007@gmail.com> On 30/05/15 15:00, Kasper Dupont wrote: > This approach works as long as key1 is not encrypted: > ssh-agent bash > ssh-add key2 > ssh -i key1 -A server1 > > But if key1 is encrypted it is highly inconvenient to have > to type my password each time I connect to server1. It is > also prone to phishing attacks, because when I type the ssh > command, how can I really know if the password prompt I see > is from ssh needing to decrypt key1 or from server1 trying > to get my decryption password. Have you considered launching a master process to server1 at the beginning of the session? That way, you will only need to provide the password for key1 once. From doctor at doctor.nl2k.ab.ca Sun May 31 08:41:18 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 30 May 2015 16:41:18 -0600 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: <5569E593.6050708@gmail.com> <20150530211235.GA20740@doctor.nl2k.ab.ca> Message-ID: <20150530224118.GA4907@doctor.nl2k.ab.ca> On Sat, May 30, 2015 at 02:38:25PM -0700, Bob Rasmussen wrote: > Would anyone like to make a 6.9 server available for testing our > client (Anzio) against? > URL to your clientware please? > On Sat, 30 May 2015, The Doctor wrote: > > >So far BSD/OS and opensh 6.9 pre works with ZOC and Tera Term. > > > >Putty and WINSCP are broken. > > > >Will test on FreeBSD 10.1 amd64 > > > >-- > >Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > >God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > >http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > >UK! Vote LDem on 7 May 2015!! > >_______________________________________________ > >openssh-unix-dev mailing list > >openssh-unix-dev at mindrot.org > >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > Regards, > ....Bob Rasmussen, President, Rasmussen Software, Inc. > > personal e-mail: ras at anzio.com > company e-mail: rsi at anzio.com > voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) > fax: (US) 503-624-0760 > web: http://www.anzio.com > street address: Rasmussen Software, Inc. > 10240 SW Nimbus, Suite L9 > Portland, OR 97223 USA > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism UK! Vote LDem on 7 May 2015!! From riedel at teco.edu Sun May 31 08:33:06 2015 From: riedel at teco.edu (Till Riedel) Date: Sun, 31 May 2015 00:33:06 +0200 Subject: FWD: enable forwarding to remote named sockets in ssh Message-ID: <556A3AA2.8040707@teco.edu> Dear openssh developers, has the problem related to remote unix socket forwarding to a local port ever been fixed? (see message below: ssh -L 12345:/tmp/sock) I could not find any code containing the patch (maybe i am looking in the wrong places) I actually had the same problem and the feature is really handy if you are working on a windows machine. Help is apreciated. Thanks! Best regards, Till Riedel -------- Forwarded Message -------- List: openbsd-tech Subject: enable forwarding to remote named sockets in ssh From: Jared Yanovich Date: 2014-08-08 20:38:11 Message-ID: 20140808203811.GK16425 () nightderanger ! psc ! edu [Download message RAW] I cannot forward to a socket on the remote host ("No forward host name."). Example: ssh -L 12345:/tmp/sock Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.336 diff -u -p -r1.336 channels.c --- channels.c 15 Jul 2014 15:54:14 -0000 1.336 +++ channels.c 8 Aug 2014 20:31:29 -0000 @@ -2771,13 +2770,18 @@ channel_setup_fwd_listener_tcpip(int typ fwd->listen_host : fwd->connect_host; is_client = (type == SSH_CHANNEL_PORT_LISTENER); - if (host == NULL) { - error("No forward host name."); - return 0; - } - if (strlen(host) >= NI_MAXHOST) { - error("Forward host name too long."); - return 0; + if (type == SSH_CHANNEL_PORT_LISTENER && + fwd->connect_path) + host = fwd->connect_path; + else { + if (host == NULL) { + error("No forward host name."); + return 0; + } + if (strlen(host) >= NI_MAXHOST) { + error("Forward host name too long."); + return 0; + } } /* Determine the bind address, cf. channel_fwd_bind_addr() comment */ -- Karlsruhe Institute of Technology (KIT) TECO - Technology for Pervasive Computing Dr.-Ing. Dipl.-Inform. Till Riedel Research Director TECO post: KIT, TecO, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany fon: +49 721 608-41706 , fax: +49 721 608-41702 email: riedel at teco.edu , web: www.teco.edu/people/riedel KIT ? University of the State of Baden-Wuerttemberg and National Large-scale Research Center of the Helmholtz Association From nkadel at gmail.com Sun May 31 11:09:46 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 30 May 2015 21:09:46 -0400 Subject: Using two agents In-Reply-To: <20150530184134.32429.qmail@stuge.se> References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> <20150530184134.32429.qmail@stuge.se> Message-ID: On Sat, May 30, 2015 at 2:41 PM, Peter Stuge wrote: > Nico Kadel-Garcia wrote: >> Mind you, I've never been complete thrilled with ssh-agent. > > Then look into extending it, or writing a new one which does what you > want. My underlying, long-term concern with ssh-agent is my underlying concern with private SSH keys. There's currently no way to enforce secure handling of them on the client side. The almost inevitable result is that people simply use unencrypted private keys, whether or not they're accumulated in an ssh-agent for access to multiple systems. And even intelligent, educated developers and sysadmins copy unencrypted private SSH keys around to remote hosts, wehter or not they are willing to use ssh-agent, because it's simpler. There are some helpful stopgaps to unlock and store access to a shareable ssh-agent for unattended system operations, such as using the 'keychain' perl script to configure and access SSH keys for an 'rsnapshot' or similar rsync over SSH based access. But the normal procedure is to not bother, and simply use unencryped private SSH keys. This is, in fact, written into dozens of "chef" and "puppet" system management cookbooks. I've been trying to spend time there trying to provide better handling of private keys, and boy, it's an uphill battle!!! >> If you really want to segregate credentials for different environments > > The agent knows who is asking it about using a key, so you could > certainly have a single agent which applies a policy based on that. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From venture37 at gmail.com Sun May 31 12:20:00 2015 From: venture37 at gmail.com (Sevan / Venture37) Date: Sun, 31 May 2015 03:20:00 +0100 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: Message-ID: Hi, Testing the portable build, On bitrig-current I get: (cd openbsd-compat && make) cc -g -O2 -Qunused-arguments -Wunknown-warning-option -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c arc4random.c In file included from arc4random.c:27: In file included from ../includes.h:180: In file included from ../entropy.h:30: In file included from ../buffer.h:24: In file included from ../sshbuf.h:23: /usr/include/stdio.h:222:44: error: too many arguments provided to function-like macro invocation __attribute__((__bounded__ (__size__,1,3,2))); ^ ../defines.h:509:10: note: macro '__bounded__' defined here # define __bounded__(x, y, z) ^ In file included from arc4random.c:27: In file included from ../includes.h:180: In file included from ../entropy.h:30: In file included from ../buffer.h:24: In file included from ../sshbuf.h:23: /usr/include/stdio.h:231:44: error: too many arguments provided to function-like macro invocation __attribute__((__bounded__ (__size__,1,3,2))); ^ ../defines.h:509:10: note: macro '__bounded__' defined here # define __bounded__(x, y, z) ^ 2 errors generated. *** Error 1 in openbsd-compat (Makefile:26 'arc4random.o') *** Error 1 in /home/sme/openssh (Makefile:156 'openbsd-compat/libopenbsd-compat.a') On NetBSD-stable I get (even with --sysconfdir=/etc being set on configure) test_kex: ....................................................................................................................................................................................WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ......WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .WARNING: /usr/local/etc/moduli does not exist, using fixed modulus ...WARNING: /usr/local/etc/moduli does not exist, using fixed modulus WARNING: /usr/local/etc/moduli does not exist, using fixed modulus .......................................................................................... 352 tests ok test_hostkeys: .................. 18 tests ok /home/sme/openssh/ssh-keygen -if /home/sme/openssh/regress/rsa_ssh2.prv | diff - /home/sme/openssh/regress/rsa_openssh.prv tr '\n' '\r' /home/sme/openssh/regress/rsa_ssh2_cr.prv /home/sme/openssh/ssh-keygen -if /home/sme/openssh/regress/rsa_ssh2_cr.prv | diff - /home/sme/openssh/regress/rsa_openssh.prv awk '{print $0 "\r"}' /home/sme/openssh/regress/rsa_ssh2.prv > /home/sme/openssh/regress/rsa_ssh2_crnl.prv /home/sme/openssh/ssh-keygen -if /home/sme/openssh/regress/rsa_ssh2_crnl.prv | diff - /home/sme/openssh/regress/rsa_openssh.prv cat /home/sme/openssh/regress/rsa_openssh.prv > /home/sme/openssh/regress//t2.out chmod 600 /home/sme/openssh/regress//t2.out /home/sme/openssh/ssh-keygen -yf /home/sme/openssh/regress//t2.out | diff - /home/sme/openssh/regress/rsa_openssh.pub /home/sme/openssh/ssh-keygen -ef /home/sme/openssh/regress/rsa_openssh.pub >/home/sme/openssh/regress//t3.out /home/sme/openssh/ssh-keygen -if /home/sme/openssh/regress//t3.out | diff - /home/sme/openssh/regress/rsa_openssh.pub /home/sme/openssh/ssh-keygen -E md5 -lf /home/sme/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/sme/openssh/regress/t4.ok /home/sme/openssh/ssh-keygen -Bf /home/sme/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/sme/openssh/regress/t5.ok /home/sme/openssh/ssh-keygen -if /home/sme/openssh/regress/dsa_ssh2.prv > /home/sme/openssh/regress//t6.out1 /home/sme/openssh/ssh-keygen -if /home/sme/openssh/regress/dsa_ssh2.pub > /home/sme/openssh/regress//t6.out2 chmod 600 /home/sme/openssh/regress//t6.out1 /home/sme/openssh/ssh-keygen -yf /home/sme/openssh/regress//t6.out1 | diff - /home/sme/openssh/regress//t6.out2 /home/sme/openssh/ssh-keygen -q -t rsa -N '' -f /home/sme/openssh/regress//t7.out /home/sme/openssh/ssh-keygen -lf /home/sme/openssh/regress//t7.out > /dev/null /home/sme/openssh/ssh-keygen -Bf /home/sme/openssh/regress//t7.out > /dev/null /home/sme/openssh/ssh-keygen -q -t dsa -N '' -f /home/sme/openssh/regress//t8.out /home/sme/openssh/ssh-keygen -lf /home/sme/openssh/regress//t8.out > /dev/null /home/sme/openssh/ssh-keygen -Bf /home/sme/openssh/regress//t8.out > /dev/null test "yes" != yes || /home/sme/openssh/ssh-keygen -q -t ecdsa -N '' -f /home/sme/openssh/regress//t9.out test "yes" != yes || /home/sme/openssh/ssh-keygen -lf /home/sme/openssh/regress//t9.out > /dev/null test "yes" != yes || /home/sme/openssh/ssh-keygen -Bf /home/sme/openssh/regress//t9.out > /dev/null /home/sme/openssh/ssh-keygen -q -t ed25519 -N '' -f /home/sme/openssh/regress//t10.out /home/sme/openssh/ssh-keygen -lf /home/sme/openssh/regress//t10.out > /dev/null /home/sme/openssh/ssh-keygen -Bf /home/sme/openssh/regress//t10.out > /dev/null /home/sme/openssh/ssh-keygen -E sha256 -lf /home/sme/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/sme/openssh/regress/t11.ok /home/sme/openssh/ssh-keygen -q -t ed25519 -N '' -C 'test-comment-1234' -f /home/sme/openssh/regress//t12.out /home/sme/openssh/ssh-keygen -lf /home/sme/openssh/regress//t12.out.pub | grep test-comment-1234 >/dev/null run test connect.sh ... Missing privilege separation directory: /var/empty FATAL: sshd_proxy broken *** Error code 1 From venture37 at gmail.com Sun May 31 12:55:47 2015 From: venture37 at gmail.com (Sevan / Venture37) Date: Sun, 31 May 2015 03:55:47 +0100 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: Message-ID: FreeBSD 10.1-RELEASE passes tests DragonflyBSD snapshot passes tests Debian 8 run test connect.sh ... Missing privilege separation directory: /var/empty FATAL: sshd_proxy broken Makefile:192: recipe for target 't-exec' failed make[1]: *** [t-exec] Error 1 make[1]: Leaving directory '/home/sme/openssh/regress' Makefile:544: recipe for target 'tests' failed make: *** [tests] Error 2 OmniOS test_sshbuf: ..................................................................................... regress/unittests/sshbuf/test_sshbuf_misc.c:35 test #86 "sshbuf_dump" ASSERT_PTR_NE(out, NULL) failed: out = 0 NULL = 0 /bin/sh: line 4: 6981: Abort(coredump) make[1]: *** [unit] Abort (core dumped) make[1]: Leaving directory `/export/home/sme/openssh/regress' make: *** [tests] Error 2 Solaris 11.2 SPARC with Solaris Studio 12.4 run test connect.sh ... Missing privilege separation directory: /var/empty FATAL: sshd_proxy broken *** Error code 1 The following command caused the error: if [ "xconnect.sh proxy-connect.sh connect-privsep.sh proto-version.sh proto-mismatch.sh exit-status.sh envpass.sh transfer.sh banner.sh rekey.sh stderr-data.sh stderr-after-eof.sh broken-pipe.sh try-ciphers.sh yes-head.sh login-timeout.sh agent.sh agent-getpeereid.sh agent -timeout.sh agent-ptrace.sh keyscan.sh keygen-change.sh keygen-convert.sh key-options.sh scp.sh sftp.sh sftp-chroot.sh sftp-cmds.sh sftp- badcmds.sh sftp-batch.sh sftp-glob.sh sftp-perm.sh reconfigure.sh dynamic-forward.sh forwarding.sh multiplex.sh reexec.sh brokenkeys.sh c fgparse.sh cfgmatch.sh addrmatch.sh localcommand.sh forcecommand.sh portnum.sh keytype.sh kextype.sh cert-hostkey.sh cert-userkey.sh host -expand.sh keys-command.sh forward-control.sh integrity.sh krl.sh multipubkey.sh limit-keytype.sh hostkey-agent.sh keygen-knownhosts.sh h ostkey-rotate.sh principals-command.sh" = "x" ]; then exit 0; fi; \ for TEST in ""connect.sh proxy-connect.sh connect-privsep.sh proto-version.sh proto-mismatch.sh exit-status.sh envpass.sh transfer.sh ban ner.sh rekey.sh stderr-data.sh stderr-after-eof.sh broken-pipe.sh try-ciphers.sh yes-head.sh login-timeout.sh agent.sh agent-getpeereid.s h agent-timeout.sh agent-ptrace.sh keyscan.sh keygen-change.sh keygen-convert.sh key-options.sh scp.sh sftp.sh sftp-chroot.sh sftp-cmds.s h sftp-badcmds.sh sftp-batch.sh sftp-glob.sh sftp-perm.sh reconfigure.sh dynamic-forward.sh forwarding.sh multiplex.sh reexec.sh brokenke ys.sh cfgparse.sh cfgmatch.sh addrmatch.sh localcommand.sh forcecommand.sh portnum.sh keytype.sh kextype.sh cert-hostkey.sh cert-userkey. sh host-expand.sh keys-command.sh forward-control.sh integrity.sh krl.sh multipubkey.sh limit-keytype.sh hostkey-agent.sh keygen-knownhos ts.sh hostkey-rotate.sh principals-command.sh; do \ echo "run test ${TEST}" ... 1>&2; \ (env SUDO="" TEST_ENV=MALLOC_OPTIONS= /bin/sh /home/sme/openssh/regress/test-exec.sh /home/sme/openssh/regress /home/sme/op enssh/regress/${TEST}) || exit $?; \ done make: Fatal error: Command failed for target `t-exec' Current working directory /home/sme/openssh/regress *** Error code 1 make: Fatal error: Command failed for target `tests' From keisial at gmail.com Sun May 31 13:07:20 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 31 May 2015 05:07:20 +0200 Subject: Using two agents In-Reply-To: References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> <20150530184134.32429.qmail@stuge.se> Message-ID: <556A7AE8.8070108@gmail.com> On 31/05/15 03:09, Nico Kadel-Garcia wrote: > My underlying, long-term concern with ssh-agent is my underlying > concern with private SSH keys. There's currently no way to enforce > secure handling of them on the client side. The almost inevitable > result is that people simply use unencrypted private keys, whether or > not they're accumulated in an ssh-agent for access to multiple > systems. And even intelligent, educated developers and sysadmins copy > unencrypted private SSH keys around to remote hosts, wehter or not > they are willing to use ssh-agent, because it's simpler. When you want unattended running over ssh even accross reboots, there's little option than having unprotected keys. I suppose you could have a setgid/setuid ssh-add able to load keys unreadable by the user that will be using that agent. But then it could trick it into loading the key into a fake agent. And if ssh-agent was running as a different user, its own protections won't allow being read by someone else. > There are some helpful stopgaps to unlock and store access to a > shareable ssh-agent for unattended system operations, such as using > the 'keychain' perl script to configure and access SSH keys for an > 'rsnapshot' or similar rsync over SSH based access. But the normal > procedure is to not bother, and simply use unencryped private SSH > keys. Does Mac OS keychain provide a more advanced solution? What is your 'keychain perl script' way? > This is, in fact, written into dozens of "chef" and "puppet" system > management cookbooks. I've been trying to spend time there trying to > provide better handling of private keys, and boy, it's an uphill > battle!!! Think that instead of key files there could be passwords there. From venture37 at gmail.com Sun May 31 14:14:52 2015 From: venture37 at gmail.com (Sevan / Venture37) Date: Sun, 31 May 2015 05:14:52 +0100 Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: Message-ID: Solaris 11.2 with GCC 4.9 test_hostkeys: regress/unittests/hostkeys/test_iterate.c:117 test #1 "hostkeys_iterate all with key parse" - entry 3/61, file line 3 ASSERT_U_INT_EQ(l->status, expected_status) failed: l->status = 0 / 0x0 expected_status = 1 / 0x1 *** Signal 6 - core dumped make: Fatal error: Command failed for target `unit' Current working directory /home/sme/openssh/regress *** Error code 1 make: Fatal error: Command failed for target `tests' Suse Enterprise 12 on IBM Power8 config.guess script is out of date, hence configure was unable to detect powerpc64le-unknown-linux-gnu Replaced script with latest from upstream to resolve the issue http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD run test connect.sh ... Missing privilege separation directory: /var/empty FATAL: sshd_proxy broken Makefile:192: recipe for target 't-exec' failed make[1]: *** [t-exec] Error 1 make[1]: Leaving directory '/home/sme/openssh/regress' Makefile:544: recipe for target 'tests' failed From htodd at twofifty.com Sun May 31 14:51:12 2015 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Sat, 30 May 2015 21:51:12 -0700 (PDT) Subject: Call for testing: OpenSSH 6.9 In-Reply-To: References: Message-ID: In NetBSD it says: skipped (SUDO not set) need SUDO to create file in /var/run, test won't work without all tests passed As root then it says: run test connect.sh ... ssh connect with protocol 1 failed ssh connect with protocol 2 failed failed simple connect I'm probably missing a readme somewhere. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee From phil.pennock at globnix.org Sun May 31 16:29:35 2015 From: phil.pennock at globnix.org (Phil Pennock) Date: Sun, 31 May 2015 06:29:35 +0000 Subject: Using two agents In-Reply-To: References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> Message-ID: <20150531062935.GA26661@tower.spodhuis.org> On 2015-05-30 at 11:25 -0400, Nico Kadel-Garcia wrote: > The workable, but fugly solution is to load an ssh-agent with the keys > you want in environment two, keep a local unencrypted private key for > permiter access to environment one stored in a shielded, protected, > ideally locally disk partition encrypted location, and set up > $HOME/.ssh/config with a "Host" entry to specify that > non-standard-location unencrypted key location to use for accessing > that permiter host or those perimeter hosts. I don't like this > solution myself, but it satisfies all the stated requirements of "I > don't want to keep typing my perimeter key passphrase" This is what we do. The reliance upon disk encryption and loss of passphrase protection is ... "unfortunate". > Mind you, I've never been complete thrilled with ssh-agent. If you > really want to segregate credentials for different environments, you > might look into Kerberos based authentication, which can provide a > very different approach to finer grained credential management. I just > wish I could get it to work with Subversion..... Each environment is distinct, in locations where we don't fully control DNS and where Kerberos is not a plausible solution. At least, I haven't considered it seriously, but I'll think on it some more. >90% sure it's not, given that one of the things I've had to log into those setups to do was to fix messed up system clocks. A bit of a chicken/egg problem if that now requires Kerberos. When I used subversion with Kerberos, I only used it with https and was always fighting some aspect of the lack of consideration for this use-case. Neon would at least allow Kerberos via WWW-Negotiate, as long as HTTPS was in use, not HTTP. -Phil From nkadel at gmail.com Sun May 31 23:46:33 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 31 May 2015 09:46:33 -0400 Subject: Using two agents In-Reply-To: <20150531062935.GA26661@tower.spodhuis.org> References: <20150530120023.GA3477@colin.search.kasperd.net> <20150530130010.GA3422@colin.search.kasperd.net> <20150530143806.GA274@tower.spodhuis.org> <20150531062935.GA26661@tower.spodhuis.org> Message-ID: On Sun, May 31, 2015 at 2:29 AM, Phil Pennock wrote: > On 2015-05-30 at 11:25 -0400, Nico Kadel-Garcia wrote: >> The workable, but fugly solution is to load an ssh-agent with the keys >> you want in environment two, keep a local unencrypted private key for >> permiter access to environment one stored in a shielded, protected, >> ideally locally disk partition encrypted location, and set up >> $HOME/.ssh/config with a "Host" entry to specify that >> non-standard-location unencrypted key location to use for accessing >> that permiter host or those perimeter hosts. I don't like this >> solution myself, but it satisfies all the stated requirements of "I >> don't want to keep typing my perimeter key passphrase" > > This is what we do. The reliance upon disk encryption and loss of > passphrase protection is ... "unfortunate". Yeah. If you have to go that route, it's well worth the extra steps to restrict the operations available to the passphrase free key. But that's a whole separate artform. Hmm. Another fugly approach is to use the first connection, with a $HOME/.ssh/config set to not forward agents to the target host, perbaps with an alias of "target-tunnel", and set up an SSH tunnel on your local server to the remote SSH. Then set up a second entry for normal connection that goes through the designated local port but *does* activate ForwardAgent. I've actually recently done something similar with the 'autossh' toolkit, to tunnel rsync over SSH connections to where I wanted them, drilling through a "jumpgate" host. This is also one of those cases where the sometimes deprecated "chroot" cage approach running an SSH daemon can be helpful, to use the first access key to access just such a "jumpgate" server and segregate typical users from seeing each other's accounts or other system information. I publish updates for the autossh 'mkchroot.sh' tool at https://github.com/nkadel/rssh-chroot-tools >> Mind you, I've never been complete thrilled with ssh-agent. If yo >> really want to segregate credentials for different environments, you >> might look into Kerberos based authentication, which can provide a >> very different approach to finer grained credential management. I just >> wish I could get it to work with Subversion..... > > Each environment is distinct, in locations where we don't fully control > DNS and where Kerberos is not a plausible solution. At least, I haven't > considered it seriously, but I'll think on it some more. >90% sure it's > not, given that one of the things I've had to log into those setups to > do was to fix messed up system clocks. A bit of a chicken/egg problem > if that now requires Kerberos. Well, yes. that's one of the "Just use NTP and use it correctly" situations pops up. But if the client host is a developer admin laptop or VM without good configuration management, yeah, life can get pretty confused. It's aggravated if the Kerberos server is on old, bog stable hardware on which the motherboard battery has expired, and you reboot it to migrate data centers, and NTP is not set to do a hard "I'm not kidding, actually reset this completely no matter how far off you are". > When I used subversion with Kerberos, I only used it with https and was > always fighting some aspect of the lack of consideration for this > use-case. Neon would at least allow Kerberos via WWW-Negotiate, as long > as HTTPS was in use, not HTTP. > > -Phil Yeah, I *wish* svn+ssh could work this way. The activation of a single user's access and credentials is currently done through "command" option among the received SSH keys. It would take an entirely different system to allow Kerberos to do this, but that's more code than I can take on.