Date: Sun, 8 Mar 2015 16:38:21 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh Message-ID: <20150308133821.GF48476@zxy.spb.ru> In-Reply-To: <alpine.GSO.1.10.1503052000210.3953@multics.mit.edu> References: <20150305123349.GP48476@zxy.spb.ru> <20150305123548.GO17947@FreeBSD.org> <48981079-C9B7-411D-87A3-5A8F04924314@FreeBSD.org> <AEB33C6A-8824-4345-81E1-95280AB20CFA@FreeBSD.org> <20150305141334.GX48476@zxy.spb.ru> <63BD8258-D2C9-4C94-8A54-63AA104871D9@FreeBSD.org> <20150305144056.GY48476@zxy.spb.ru> <CAJ5_RoBk=5C2%2BMktu_ODc7C%2BNraUhiSprtKd-=3bj%2Bb5UPT_1g@mail.gmail.com> <20150305151732.GA48476@zxy.spb.ru> <alpine.GSO.1.10.1503052000210.3953@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 05, 2015 at 08:14:59PM -0500, Benjamin Kaduk wrote: > On Thu, 5 Mar 2015, Slawa Olhovchenkov wrote: > > > On Thu, Mar 05, 2015 at 10:11:43AM -0500, Benjamin Kaduk wrote: > > > > > On Thu, Mar 5, 2015 at 9:40 AM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > > > > > > Speaking as an upstream maintainer: don't use kerberized telnet. > > > > I am use this for test kerberos setup (check all setup correctly). > > I use ssh to test kerberos setups (I think sshd has better error message, > for one). I don't see any error message from ssh (about kerberos), ssh just ask password if any problem. What a problem? Silent. For debug ssh+kerberos I need stop sshd and run sshd with -D and -d. And in this case debug messages very stranges for me. Also, telnet use less dependes and less restrictions. This is good for step-to-step debug. > The problem with using telnet to test the kerberos setup is that if your > kerberos setup works with telnet, you have the DES enctypes (weak > cryptography) enabled. This means that the whole setup, even things > other What you talk about DES? I don't see nothing about AES/DES/etc in krb5.conf. > than telnet, are suffering from the vulnerabilities of weak crypto. > Kerberos distributions have disabled DES by default for many years, now -- > Apple has even completely removed the code for them from recent releases > of OS X! Please see RFC 6649. I don't enable DES. And I have working kerberized telnet. What you talk about? > > > I use kerberized ssh all the time; please tell me more about how it is > > > broken (a new thread would be best). > > > > kerberized ssh broken in SSO mode: you can't do ssh login to > > I have a very different idea of what "SSO mode" means: I run kinit on my > local machine and then use kerberos to authenticate to remote > services. I SSO (for me) is from Windows world: you login in desktop and don't need to enter password anymore. > should never type my password at something which is not a trusted local > binary. As I know, you can't use kerberos outside controled perimeter (with working NTP sync, revers DNS and etc). I.e. from random [network] place you can't run kinit on local machine [notebook] and use kerberos to ssh login. For may case this is requirement. And for untrusted binary -- why don't use kerberos with OTP? > > kerberized host (from outside world), input kerberos password and use > > kerberos ticket. > > "input kerberos password and use kerberos ticket" doesn't make sense -- > you are not using your kerberos ticket; you are using your password. > PAM I am use kerberos ticket for passwordless login to internal hosts (after using password for login to gateway host). > is going off and getting a ticket, sure (and hopefully validating it > against the host keytab to avoid the Zanarotti attack!), but it is > starting with your password. That is completely at odds with how Kerberos > is intended to be used. Sorry, I don't understand you. Can explain? > > This is issuse between PAM and ssh thread emulation. > > It does seem likely that this sort of thing would be an issue with PAM, > yes. I am not particularly motivated to look into it, though. > I do recall some issue where sshd in capsicum mode was not allowed to read > the keytab in order to verify the supplied Kerberos credentials, which > required using UsePrivilegeSeparation=yes instead of the default value > (sandbox). Perhaps that would affect the password mode of operation as > well. Currently, sshd for PAM (and kerberos PAM) fork child. Got ticket in this child. And try to save ticket in parent (unsuccessful, of course). As result -- I don't have valid ticket after ssh login.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150308133821.GF48476>