similar to: Extra newlines in sshd login messages

Hi All, I have found that the regression tests on AIX failed as a non-root user. This is due to a call to loginrestrictions() failing. The man page for loginrestrictions says: "Access Control:The calling process must have access to the account information in the user database and the port information in the port database." These files are: /etc/security/user,

Hi All. I've decided to try to merge the -Portable parts of the password expiry patch (see bug #14) that do not depend on the OpenBSD change in bug #463. The attached patch is the first step in this process. It removes the AIX-specific "char *aixloginmsg" and replaces it with a platform-neutral "Buffer loginmsg". I think this is worth having in -Portable even if it

Hi. There's a couple of minor problems with the way port-aix.c handles the messages returned by AIX's authentication routines. I think we handle the native ones OK, but third-party modules might behave differently. It tests OK for me, I would appreciate testing by anyone using AIX (esp. anyone using something other than the standard password auth modules). a) The message from a

Hi. If sshd is configured to use PAM and UsePrivilegeSeparation=no or you are logging is as root, any messages returned by PAM session modules are not displayed to the user. (Even when the config file has privsep=yes, logging in as root disables privsep anyway since there's no point, so it behaves the same way as privsep=no). I think I've figured out why: when privsep=no,

Hi All. Attached is a patch that converts pam_chauthtok_conv into a generic pam_tty_conv, which is used rather than null_conv for do_pam_session. This allows, for example, display of messages from PAM session modules. The accumulation of PAM messages into loginmsg won't help until there is a way to collect loginmsg from the monitor (see, eg, the patches for bug #463). This is because the

Hi All. With one eye on the do_pam_chauthtok() stuff I've merged contributions by Pablo Sor and Mark Pitt into a patch against -current. I'm interested in testers and suggestions for improvements. The patch extends the loginrestrictions test to include expired accounts (but unlike Mark's patch, doesn't log accounts with expired passwords unless they're locked) and adds

Hi all. The old (~3.6.x) PAM code used to send PAM messages to stderr, whereas the new generic loginmsg code sends them to stdout, and it sends an extra newline. I think stderr is probably right, but the extra \n should probably be removed either way. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with

This is an attempt to simplify the AIX expiry-via-passwd stuff and make it more generic. (There's actually a net reduction in #ifdefs). Patch against CVS: 1) configure finds passwd. 2) sshd uses passwd during session if required. 3) sshd uses passwd for PAM change if privsep disabled. 4) sshd uses Buffers for expire and post-login messages (no longer AIX specific). 5) password_change_required

Hi All. This patch calls pam_chauthtok() to change an expired password via PAM during keyboard-interactive authentication (SSHv2 only). It is tested on Redhat 8 and Solaris 8. In theory, it should have simply been a matter of calling pam_chauthtok with the PAM_CHANGE_EXPIRED_AUTHTOK flag, it'd only change the password is if it's expired, right? From the Solaris pam_chauthtok man page:

Hi All. Attached is another patch that attempts to do pam_chauthtok() via SSH2 keyboard-interactive authentication. It now passes the results from the authentication thread back to the monitor (based on a suggestion from djm). Because of this, it doesn't call do_pam_account twice and consequently now works on AIX 5.2, which the previous version didn't. I haven't tested it on any

Hi All. Attached is a patch to perform pam_chauthtok via SSH2 keyboard-interactive. It should be simpler, but since Solaris seems to ignore the CHANGE_EXPIRED_AUTHTOK flag, it calls do_pam_account to check if it's expired. To minimise the change in behaviour, it also caches the result so pam_acct_mgmt still only gets called once. This doesn't seem to work on AIX 5.2, I don't know

Hi All. Attached is a patch introduces password expiry handling for AIX (other platforms to follow). It is more or less the same as the previous patch but has been updated to reflect recent changes to auth-passwd.c I'm wondering if the AIX parts of auth.c should be moved to port-aix.c and if the generic password change functions (currently at the end of auth-passwd.c) belong in a separate

Hi All. Attached is a patch which adds AIX native password expiry support to sshd. It will only apply to -current and is a subset of the patch I have been working on in the last few months (see bug #14 [1]). It contains code by Pablo Sor, Mark Pitt and Zdenek Tlusty and fixes for bugs reported by many others (see [2] for a full list). It adds a do_tty_change_password function that execs

Hi Damien, I noticed you merged a couple of ifdefs in the fix for bug #442. The cvs comment says "Fix Bug #442 for PAM case". The code is now roughly: #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) spw = getspnam(pw->pw_name); passwd = spw->sp_pwdp; #else passwd =

Hi. One thing that people seem to want to do with PAM is to deny a login immediately without interacting but return a message to the user. (Some platforms implement, eg, /etc/nologin via PAM this way.) Currently, sshd will just deny the login and the user will not be told why. Attached it a patch that return a keyboard-interactive packet with the message in the "instruction"

Olli Savia wrote: > The attached patch is a port of the current CVS (2005-08-11) version > of OpenSSH portable to LynxOS. Could you consider adding it to the > future releases of OpenSSH? If the patch needs additional work, please > let me know. Looks mostly reasonable, some comments and questions below. > + AC_DEFINE(LYNXOS_BROKEN_SETVBUF, 1, [LynxOS has broken setvbuf()

Is there a problem with the snapshots? The newest one on ftp.ca.openbsd.org is a week old. -Daz. -- 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.

Does anyone actually use sshd on a system that doesn't have socketpair? It's used elsewhere so the don't-have path seems like it'd never be exercised these days. Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v retrieving revision 1.147 diff -u -p -r1.147 monitor.c --- monitor.c

Hi All. For a couple of weeks, the Portable snapshots have contained optional support for NetBSD's libedit in the sftp client, thanks to djm's work in OpenBSD. It's enabled with: ./configure --with-libedit. If enabled, sftp gains command history, recall and line editing (and probably other features too, I haven't looked into libedit's capabilities much). If not

I am just looking for a quick answer as to whether or not OpennSSH is compatible with Digital Unix Tru64 v 4.0F. Hing Fei Wong Systems Engineer Building 100, M1309 Valley Forge, PA Admin # 4-6242 -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Friday, June 23, 2006 3:53 AM To: Wong, Hing Fei Cc: www at openbsd.org Subject: Re: OpenSSH compatibility with