search for: mm_answer_pti

Hi, I'm trying to use connect to an openssh server, setting some terminal modes, and they don't seem to do what I want. Specifically, I'm trying to disable echo from the server - hence the four modes in the sshd trace below (53 for example is ECHO). I've looked at the code. 0 would indicate that the option is negated in the c_lflag field. And it seems like the modes are

Hi, I posted this before (I thought) but I'll give it another try (looks like it arrived on the list on Saturday). :-( I'm trying to connect to an openssh server, and setting some terminal modes. However, they don't seem to do what I want. Specifically, I'm trying to disable echo from the server - hence the four modes in the sshd trace below (53 for example is ECHO).

Because OpenSSH_5.4 doesn't build on my OpenBSD 4.2 box, I tried OpenSSH_5.4p1 which builds and installs fine. After starting server with sudo /opt/sbin/sshd -p 2222 -d, my ssh client can connect, but the session is closed by server as soon as it is started: [...] User child is on pid 10318 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1:

This privsepifies OSF/1 SIA, but I'm still being told the same error occurs. I'm stumped. Without an OSF/1 box near me I can't do too much more help unless someone can either tell me what is wrong or show me why SIA is failing in their logs. (And tell me if it's different w/ or w/out this patch) - Ben Index: auth-sia.c

Ok.. I need wider testing for this. I'm getting reports back it works mostly. 'ssh site ls' fails, but they can login with Privsep enbled. Can I get those who are using Tru64 or OSF/1 that have SIA enabled to test? This should apple to either -cvs or the current snapshot (I would perfer not to use 3.4p1 due to bugs). I'm going on a trip next week and will be around very spotty

Hello All. Attached is an update to my previous patch to make do_pam_chauthtok and privsep play nicely together. First, a question: does anybody care about these or the password expiration patches? Anyway, the "PRIVSEP(do_pam_hauthtok())" has been moved to just after the pty has been allocated but before it's made the controlling tty. This allows the child running chauthtok to

All, I'm working on upgrading a machine from RH 6.2 to RH 8.0. I've encountered one major (for me) snag in that I cannot get X11 forwarding to work anymore. I've been google-ing the error messages all morning, with no luck. Here is debugging output from the server (client debugging output sent upon request... I don't feel it is relevant). What I feel is interesting is at the

https://bugzilla.mindrot.org/show_bug.cgi?id=2856 Bug ID: 2856 Summary: key-options.sh fails when pty /dev/ttyp1 is not owned by testing user Product: Portable OpenSSH Version: 7.6p1 Hardware: ix86 OS: NetBSD Status: NEW Severity: minor Priority: P5 Component:

http://bugzilla.mindrot.org/show_bug.cgi?id=585 ------- Additional Comments From dtucker at zip.com.au 2003-07-07 00:32 ------- dmalloc (http://dmalloc.com/) claims to work on IRIX. It's likely to increase the CPU and memory load, though. I've built with dmalloc on Linux thusly: LDFLAGS=-ldmalloc ./configure && make eval `dmalloc -l /path/to/log high` ./sshd [options]

Hi All. Attached is a patch that implements password expiry with PAM and privsep. It works by passing a descriptor to the tty to the monitor, which sets up a child with that tty as stdin/stdout/stderr, then runs chauthtok(). No setuid helpers. I used some parts of Michael Steffens' patch (bugid #423) to make it work on HP-UX. It's still rough but it works. Tested on Solaris 8 and

Either this never made it to the list or no one cares about Tru64. This is the last time I'll send this patch to the list. If no one steps up and finishes it or provides me with enough information to fix any remaining bugs (one being complaint that 'ssh site cmd' does not work right). If there is no activity on this for a week. I'll post it to bugzilla and will ignore any

http://bugzilla.mindrot.org/show_bug.cgi?id=544 Summary: sshd w/privsep fails on Linux 2.0, mm_receive_fd: expected type 1 got 1074276337 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd

Occasionally, we're noticing that sshd is core dumping on our IRIX 6.5.18f machine. The only time we've really noticed it is when users are logging in with putty from offsite (although I'm not really sure it's a client issue). The user manages to log in, sshd apparently core dumps, but the user is not logged out, the privilege separated user is still running their own

Hello, I'm not sure if this has already been addressed, I looked through the archives and can't seem to find anything. I also did some Usenet searching and only found one article mentioning this, and it was in French. Anyway, the problem is that it appears as though when using privsep opensshd doesn't execute pam_session as root, and this causes pam_mkhomedir to fail.

Hello, I'm a novice system programmer and I need some knowledge about how sshd/PAM/NSS work together. The email may be long and unclear, but I would greatly appreciate if any one could give me some info. TIA. I'm developing a new authentication module for Linux login service. I'm like a novice developer in this area, so I had to study this and that. I started with PAM naively,

OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch to 3.4p1. Partial success, in that it now works for me for logins to "root". Logins to ordinary accounts fail after authentication, when trying to set tty characteristics. See the excerpt from the debug messages below. This is for Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time

http://bugzilla.mindrot.org/show_bug.cgi?id=333 ------- Additional Comments From stevesk at pobox.com 2002-07-04 05:41 ------- i will guess configure did not find an xauth when it was built ($PATH is irrelevant here). please verify. see $HOME/.ssh/rc example in sshd.8 which can be used as a workaround in this case. djm: autoconf-2.53 exposes a bug for xauth path detection. ------- You

Hi. There should be a checklist of everything that can go wrong with making an ssh connection. Here's one entry for the list, which I didn't know before, and * I couldn't see the problem from the -ddd and -vvv output, and * there were no /var/log/* file entries to give hints. Here's what I did sudo kill <pid-of-sshd> /usr/sbin/sshd No good. Usually I did kill

Hi Darren/Damien, Sorry for responding so late. Still hope we can get this sorted out. Yes I am indeed using PAM for ssh authentication and disabling priv seperation is a no-go for us since it opens up a security loophole. From what I can see in ptree and auth logs, when the child passwd process returns with SIGCHLD, the parent sshd process terminates. Sshd logs are as follows as requested at

Hi- I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it *almost* works. I get in from the client side and xauth is run, but in the meantime the server side disconnects. Running sshd in debug mode level 3 gives the following output: . . . debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: channel 0: rfd 13