similar to: patch almost works on 5.1A openssh 3.4p1 - get in, but get kicked out (fwd)

Hi- Since the tru64 patch was designed for -current, I thought I would try to build it with a recent snapshot before backporting to 3.4p1. So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it does not contain the 'configure' script. I tried copying the 'configure' from 3.4p1, but that does not create a Makefile from the Makefile.in. Where are the

Hi- Unfortunately, I just found out about the patch that was available for tru64 privsep. I was entirely unaware that there was a lack of support. Will the patch be considered for approval if it is applied to 3.4p1, or does it have to be done against -current? The reason I'm asking is that I have 3.4p1 working as is, so I know if I have a problem it is likely related to the patch and not

What do we loose by not having post-auth privsep? What code is executed between authorization and actual setting of the effective uid? On Tue, 3 Sep 2002, Chris Adams wrote: > Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said: > > It appears that the integration of the sia session setup will either > > have to be rethought or abandoned

Hi- Under privsep, I experimented with moving the session_setup_sia() out of do_child() and into do_setusercontext(), which is where the uids/gids are set to the final execution user. The call is made with a NULL tty, and this is functional provided that any later pty allocation uses grantpty() to set the device permissions. Logging in with this method shows that a utmp entry does get made for

Hi- I built openssh-3.0p1 on a Tru64 4.0G without any problem. The system uses enhanced security, so the sia_* routines are used by sshd. Unfortunately, password authentication fails because sia_ses_authent() returns 0 in auth-sia.c. The thing is, the password is CORRECT; I verified this by inserting debugging statements before the call to sia_ses_authent(). The call to sia_ses_init()

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

With 3.3p1 built on AIX 4.3.2: $ ssh [blah] Couldn't set usrinfo: Not owner debug1: Calling cleanup 0x20019080(0x200219a0) debug3: mm_request_send entering: type 27 debug1: Calling cleanup 0x20018dd4(0x0) Connection to songohan closed by remote host. Connection to songohan closed. Output from sshd -d -d -d: ... debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0

Hello, I am porting the Openssh3.4 code to a proprietary operating system. I am running into the issue of ssh client disconnecting with a message - Disconnecting: Bad packet length 2782384553. This happens only when there is a large (~100k) output of some command executed on the remote system. If the output is not large then it doesn't happen. I tried with different encryption algorithm

<Snip> debug1: server_input_channel_req: channel 0 request x11-req reply 0^M debug1: session_by_channel: session 0 channel 0^M debug1: session_input_channel_req: session 0 req x11-req^M debug1: bind port 6010: Can't assign requested address^M debug1: fd 11 setting O_NONBLOCK^M debug2: fd 11 is O_NONBLOCK^M debug1: channel 1: new [X11 inet listener]^M debug1: server_input_channel_req:

Here's the appropriate output with blow-by-blow explanation embedded... I start by making a connection with X11 forwarding enabled: polycut:~> ssh -v -v -v -X dazel OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /opt/openssh-2.9.9p2/etc/ssh_config debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 23 msec debug3:

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.

Hi Toni, I'm sorry, I haven't had much time to work on this today. When I run sshd (from the patched snapshot) in a debugger, with a breakpoint early in setup_sia(), this is what I find after connecting with a client: (1) There are two sshd processes. One is running as root, and the other as the user I logged with using the client. The root process is the one in the debugger,

http://bugzilla.mindrot.org/show_bug.cgi?id=429 Summary: SSH 3.4p1 problems on Tru64 V4.0D & Tru64 V4.0F Product: Portable OpenSSH Version: 3.4p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org

It still is not right, but thanks to Steve we have gotten this far.. The issue seems to be here: debug3: entering: type 26 debug3: entering debug1: session_new: init debug1: session_new: session 0 debug3: entering: type 26 : sendmsg(12): Invalid argument debug1: Calling cleanup 0x1200365c0(0x14000d9d8) debug1: session_pty_cleanup: session 0 release /dev/ttyp4 debug1: Calling cleanup

http://bugzilla.mindrot.org/show_bug.cgi?id=179 Summary: sshd sends channel data after sending EOF Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 URL: http://www.denisbider.com OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=375 Summary: sshd core dumping with msg "Cannot delete credentials" Product: Portable OpenSSH Version: 3.1p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org

Hello. Since some days I cannot use scp anymore but ssh login work. Reinstall did not help. I do not exactly what has changed but I now it used to work. sshd runs on a firewall-bastion host (Linux SuSE 9.2). Firewall is open on port 22 for local network. Even tried all open (in and outgoing). Between the clent and the firewall-bastion is another nat-router. Works with ssh, though. The

Hi, I am still having difficulties in logging in as a non root user. I have installed 3.4.p1. I am logging in from a Linux box that has been upgraded to 3.3p1 and experience no problems in loggin in to other linux boxes, root or non-root. Output from ./configure OpenSSH has been configured with the following options: User binaries: /usr/local/bin System

Hi openssh developers! I have the following problem: ssh works very fine, but scp fails as soon as it wants to start the actual transfer: --------------- screenshot ------------------ martin at donald:/home/martin$ scp -v -v -v joke mpitt at piware.de: [...] debug1: Authentication succeeded (publickey). debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new

Hi, I was given you name by a colleague of mine as someone who may be able to help me with ssh and Cygwin. I've set up Cygwin and ssh - but every time I run ssh it asks me for my password. I want to set this up so I can use keys for the user and host pair to stop this happening, but have had no success. The id_dsa.pub file generated by ssh-keygen actually starts with "ssh-dss",