similar to: Hanging ssh session...

I'm having trouble getting any sort of work-around for 3.10 on Solaris 8 with Sun's tcsh. I've tried using "hup" to correct it but to no avail. This problem wasn't present with ssh version 1 - it just seem to work. Now we get all kinds of abandoned ssh processes lying around that have to be manually killed. Does anyone know if there is going to be a fix for this problem

Hi, I'm not a programmer nor able to fully understand the code of openssh in detail - hence my question here. Out of curiosity I was looking at the patch for CVE-2002-0083 and tried to understand what the actual problem is, but failed: --- channels_old.c?? ?Mon Mar? 4 02:07:06 2002 +++ channels.c?? ?Mon Mar? 4 02:07:16 2002 @@ -151,7 +151,7 @@ ?channel_lookup(int id) ?{ ??? ?Channel *c; -??

When I run a remote xterm, the ssh hangs even after I quit the xterm. Below is the output for the following sequence: client> ssh -v -v -v dazel xterm xterm> exit client> ^C The outcome is always the same - the ssh doesn't exit with I quit the xterm... I have to hit CTRL-C on the client side. polycut:~> ssh -v -v -v dazel xterm OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL

The reason I ask about the patches is because I think the problem you're seeing might actually be a bug in pam_unix.so.1 - it's something to try at least. We don't use password aging and we don't use the "passwd" command to change passwords, so we haven't run into this at our site even though we probably don't have pam_unix.so patched up. Also, the passwd

The progress fix listed [quote] - If rsync exits in the middle of a --progress output, it now outputs a newline to prevent the progress line from being overwritten. [/quote] Appears to not work. == Test 1 == CTRL+C is used to abort:- rsync -av --whole-file --progress -e "ssh -p 23" test1:/test/ /test/ receiving incremental file list zone/english/ zone/english/mp_carentan1.ff

It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes make to fail immediately after running configure. Ed Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key

In do_pam_cleanup_proc(), there are 3 calls to PAM: 1) pam_close_session() - do lastlog stuff 2) pam_setcred(PAM_DELETE_CRED) - delete credentials 3) pam_end() - close PAM It appears that pam_setcred() always fails with the error PAM_PERM_DENIED. This is due to a check done pam_unix.so to not allow a caller with euid 0 to even try to delete their SECURE_RPC credentials. When sshd calls

Hi, Sorry no core dumps, the sshd programme is perfectly happy just fails to consider changing the password. Cheers, Martyn -----Original Message----- From: Ed Phillips [mailto:ed at UDel.Edu] Sent: 06 November 2001 18:38 To: Roberts,M,Martyn,IVLH4 C Cc: openssh-unix-dev Subject: Re: Solaris 7 changing password via PAM On Tue, 6 Nov 2001 martyn.a.roberts at bt.com wrote: > Date: Tue, 6

Hi, i am experiencing a problem with ssh 3.0.2.p1 running on Solaris 2.8. Everything works fine with local users (i.e. with local passwd and shadow entries). With LDAP authenticated users, i obtain: treno at tao[!] -> ssh -v Segmentation Fault (core dumped) The probem is the same with 2.x releases. Thank you, Roberto Bertucci

Hi there, I just tried out OpenSSH3.0p1 running on Solaris 8 with PAM (--with-PAM). The problem was mentioned some time ago and is still there :-( When a password is expired you are prompted to change it now, enter your login password and after doing so you are instantly disconnected. I think this is a problem with PAM and not SSH, but how can I get a solution on this ? sshd is running without

Please review the function below, forkoff(), meant to be used in clientloop.c instead of daemon() and the code in process_escapes(). The intention is to make ~D ( like ~& but also detach) possible and to make it possible for ssh -f (or ssh -f -f - see other thread on this) to detach, not just forkoff(). I also intend to use the same detach technique in a feature patch for the hang-on-exit

On 06.07.23 23:37, MCMANUS, MICHAEL P wrote:> So changing the forced command as stated will break the application. I > would need to create a test bed to simulate the listener rather than > use the server as is, where is. That may produce false or misleading > results. Since the forced command is tied to the specific keypair in the authorized_keys, you could -- test with a different

I don't know if this is still a problem in the latest snapshot, but with 2.9.9p2, if you do a "./configure ... --with-tcp-wrappers", there's no way to specify a location for tcpd.h and libwrap.a. This is troublesome on Solaris where you might install stuff like that in /opt/lib or /usr/local/lib or something that is not searched by default. Ed Ed Phillips <ed at

If I change openbsd-compt/readpassphrase.c and type "make" from the top-level, nothing happens. I have to remove openbsd-compat/libopenbsd-compat.a to get "make" to do its thing. Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key

Can someone tell be briefly how to get OpenSSH3.1p1 configured and compiled to use /dev/random? Can OpenSSH use /dev/random directly now? Thanks, Ed Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key

I'm guess I wasn't following the whole cookies discussion completely (putting cookies in /tmp to avoid putting them on NFS, etc.), but I noticed today that with 2.9.9p2, if I use "ssh -X" to start a shell on the server, in that shell XAUTHORITY is set to /tmp/ssh-XXXXXXXX/cookies and there are cookies placed there there. These are the "fake" cookies for the

This (very quick) patch allows you to connect with the commercial ssh.com windows client and use x509 certs for hostkeys. You have to import your CA cert (ca.crt) in the windows client and certify your hostkey: $ cat << 'EOF' > x509v3.cnf CERTPATHLEN = 1 CERTUSAGE = digitalSignature,keyCertSign CERTIP = 0.0.0.0 [x509v3_CA]

I've been doing so more tests with 2.9.9p2 on Sol8. Here are my finding so far: When a user needs to change his password and trys to run a command in non-interactive mode, it just succeeds without even trying to prompt the user for a new password. Damien submitted a fix - it works for me (is it going into CVS?). When a user needs to change his password and trys to login in interactive

(I vaguely remember talk about PAM session stuff recently... please excuse me if this is the same problem.) I compiled v2.9.9p2 on Solaris 8 with the following configuration and the Sun Workshop v5 compiler: OpenSSH has been configured with the following options: User binaries: /opt/openssh-2.9.9p2/bin System binaries: /opt/openssh-2.9.9p2/sbin

I tried replacing readpassphrase() for v2.9.9p2 on Sol8 with a different version that just calls getpassphrase(). It appears to solve the echo problem when the user tries to login in interactive mode and needs to change their password. Can anyone else try this with v2.9.9p2 on Solaris? Be sure to add: #define HAVE_GETPASSPHRASE ... to config.h when compiling (since it's not a configurable