similar to: openssh-2.1.0 and AFS

For some reasons the afs tokenforwarding stuff has changed siginificantly from v 2.9p2 to 2.9.9p2. This makes it impossible to use public key authenticication in a standart AFS environment. I don't know the reasons for these changes. In any case attached is a patch which restores the old behaviour. Regards Serge -- Serge Droz Paul Scherrer Institut mailto:serge.droz at

Here is a patch I just wrote and tested which may be of interest to those who wish to use KerberosGetAFSToken (currently requires Heimdal libkafs) in combination with GSSAPIDelegateCredentials. The patch is in the public domain and comes with no warranty whatsoever. Applies to pristine 3.8p1. Works for me on Solaris and Tru64. I'd probably have used Doug Engert's patch from 2004-01-30 if

I have a few patches for AIX. The patchfile is attached below. The patch has been tested on AIX4.2 and AIX4.3. The patch is on openssh-1.2.1pre25, with openssl-0.94, using RSAref. 1) authenticate support - this function allows the system to determine authentification. Whatever the system allows for login, authenticate will too. It doesn't matter whether it is AFS, DFS, SecureID, local.

Hello, I came across an interoperability problem in OpenSSH 3.0p1 and 3.0.1p1 concerning the AFS token forwarding. That means that the new versions are not able to exchange AFS tokens (and Kerberos TGTs) with older OpenSSH releases (including 2.9p2) and with the old SSH 1.2.2x. In my opinion this problem already existed in Openssh 2.9.9p1, but I have never used this version (I only looked at the

Hi All. Recently a change was merged from OpenBSD's sshd into Portable that implements a KerberosGetAFSToken option (patchset attached). This change causes compile errors with both MIT Kerberos and Heimdal (errors when compiled with MIT Kerberos below). I've figured out that the functions called in the new code are in Heimdal's libkafs, so adding -lkafs to the start for the

Hello, I going to use ssh with Kerberos V5 support along with support for AFS. I don't want to use Kerberos V4 or AFS token passing. The only thing I need from AFS is creating an AFS token (using appropriate function from krb5 API) after user's authentication. It seems to me that such scenario is not much supported by the current code. Rather it is assumed only Kerberos 4 will be used

With a little help, I managed to get ssh to compile. (original post 05.02.02) Now, I can login using an account that is local to the target machine but logins with AFS accounts fail. The details: IRIX 6.5.15 ssh 3.1.p1 gcc 3.0.1 ssl-0.9.6c zlib-1.1.4. I am configuring with: env CC=gcc CFLAGS=-g LDFLAGS=-Wl,-rpath,/usr/local/krb4/lib,-rpath,/usr/local/ssl/lib ./configure

http://bugzilla.mindrot.org/show_bug.cgi?id=118 Summary: Implement TIS (protocol 1) via PAM Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: fcusack at

Could people please test -current? We will be making a release fairly soon. -d -- | By convention there is color, \\ Damien Miller <djm at mindrot.org> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE)

Could everyone please test the latest snapshots as we will be making a new release soon. If you have any patches you would like us to consider, please resend them to the list ASAP. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer

Hello, appended is a patch that makes it possible to use PAM both for password authentication and TIS (i.e. s/key or opie or any other interactive challenge/response scheme). I have developed this starting from the patch at http://www.debian.org/Bugs/db/61/61906.html on Debian with openssh-2.1.1p4-3. After configuring ssh with --with-pam-tis, there are two PAM services, "sshd" and

Hi there, everyone; I've had a few requests for an updated version of my chroot patch. (the version found in contrib is outdated) So, here it goes, updated to 2.3.0p1; "chroot.diff" is a plain diff for session.c (apply, compile and go). "chroot+configure.diff" is the same patch, plus an option to "configure" for enabling/disabling chroot support (./configure

The primary purpose of the attached patches is for portable OpenSSH to support changing expired passwords as specified in shadow password files. To support that, I did a couple enhancements to the base OpenBSD OpenSSH code. They are: 1. Consolidated the handling of "forced_command" into a do_exec() function in session.c. These were being handled inconsistently and allocated

I am not 100% positive of the security implications of this, but I really can't see any potential for harm. If this patch is applied (I coded it against the now-current openssh-2.2.0p1), then if (a) the authorized_keys entry has command="whatever" to force a specific command, and also (b) the invoker specified some command on their ssh cmdline, then the invoked command will be

Hi, We at BalaBit IT Security Ltd developed a patch against openssh 2.3.0p1 to support TIS authserv authentication. TIS authserv uses a simple protocol, and supports CryptoCard, SKey, password etc. authentication. The commercial versions of SSH support this protocol, OpenSSH implemented SKey on its own using the protocol primitives originally invented for TIS authentication. Our patch is an

I am a recent convert to openssh. I am very pleased with it, and find it superior to ssh-1.2.27 in many ways (thanks for the good work). I recently found one piece missing from the current release. I have used the 'command' option in the authorized_keys file to restrict access. Using ssh-1.2.27 the original command was placed in the SSH_ORIGINAL_COMMAND envrionment variable. If

(I think the subject is quite descriptive; however for use-cases and details see bellow after the mention of the old conversation and the patch.) Searching the mailing list about this topic yields an old conversation about this from 2008: * https://lists.samba.org/archive/rsync/2008-November/022148.html * https://lists.samba.org/archive/rsync/2008-November/022150.html I'll quote

The native authentication methods of openssh are (not counting insecure RhostsRSAAuthentication) 1) public key 2) password For users with home dirs in AFS space, method 1) does not work. Except with (non foolproof) fiddling on the access controls within the home directory. This might lead to security issues when done by inexperienced users. Without some work, only 2) remains. Being forced to send

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have just uploaded openssh-1.2pre15 to http://violet.ibs.com.au/openssh/ Changes: - Merged big source cleanup from OpenBSD CVS. All the source now conforms to: http://www.openbsd.org/cgi-bin/man.cgi?query=style&apropos=0&sektion=9&manpath=OpenBSD+Current&format=html - Added BSD compatible install program - More

Rather then implementing kafs in MIT Kerberos, I would like to suggest an alternative which has advantages to all parties. The OpenSSH sshd needs to do two things: (1) sets a PAG in the kernel, (2) obtains an AFS token storing it in the kernel. It can use the Kerberos credentials either obtained via GSSAPI delegation, PAM or other kerberos login code in the sshd. The above two