similar to: [Bug 711] 3.7.1p2 does not compile on redhat 5.1

Engine keys are keys whose file format is understood by a specific engine rather than by openssl itself. Since these keys are file based, the pkcs11 interface isn't appropriate for them because they don't actually represent tokens. The current most useful engine for openssh keys are the TPM engines, which allow all private keys to be stored in a form only the TPM hardware can decode,

Dear developpers, I'm using OpenSSH_2.9p1 with prngd on my Sony NEWS-OS 4.2.1R. NEWS-OS 4.x is based on 4.3BSD and lack of many POSIX and ANSI features. Today I tried to make the latest openssh_cvs and got the following error, gcc -g -O2 -Wall -O -I. -I.. -I. -I./.. -I/usr/local/ssl/include -DHAVE_CONFIG_H -c readpassphrase.c readpassphrase.c: In function `readpassphrase':

Engine keys are private key files which are only understood by openssl external engines. ?The problem is they can't be loaded with the usual openssl methods, they have to be loaded via ENGINE_load_private_key(). ?Because they're files, they fit well into openssh pub/private file structure, so they're not very appropriately handled by the pkcs11 interface because it assumes the private

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

One of my users found that the new ssh-add, from the portable OpenSSH CVS as of October 12, was hanging in his .profile while trying to start up CDE (Common Desktop Environment) on Solaris 2.6. The previous one, which was from OpenSSH 2.9p2, did not hang. It turns out that CDE, at least on Solaris 2.6, 7 and 8, runs the user's .profile with a special startup shell that allocates a pseudo-tty

The OpenSSH and ssh.com agents use a completely different set of messages for dealing with DSA keys, so I don't expect the OpenSSH client to be able to get DSA keys from ssh-agent2. However, if I'm running "ssh-agent2 -1", I expect OpenSSH to be able to use RSA keys stored in ssh-agent2's agent1 compatibility box. And it does. However, there's a problem. If I'm

I've architected this in a way that looks future proof at least to the openssl provider transition. What will happen in openssl 3.0.0 is that providers become active and will accept keys via URI. The current file mechanisms will still be available but internally it will become a file URI. To support the provider interface, openssl will have to accept keys by URI instead of file and may

I don't remember what we did to fix this last time, and I've had to rebuild my system completely from scratch over the past few days, so dont' have past patches to work from ... new-relay:/usr/slocal/src/openssh-1.2pre15> make gcc -g -O2 -Wall -I/usr/slocal/include -DETCDIR=\"/usr/local/etc/ssh\" -DSSH_PROGRAM=\"/usr/slocal/bin/ssh\" -DHAVE_CONFIG_H -c

http://bugzilla.mindrot.org/show_bug.cgi?id=377 Summary: Reduce compiler warnings. Use unsigned args to the ctype.h is*() macros. Product: Portable OpenSSH Version: -current Platform: Sparc OS/Version: Solaris Status: NEW Severity: trivial Priority: P2 Component: Miscellaneous

this line seemed to have been dropped somewhere b/w 3.1 and 3.5 --- openssh-3.5p1/openbsd-compat/readpassphrase.c.orig Tue Sep 10 20:29:13 2002 +++ openssh-3.5p1/openbsd-compat/readpassphrase.c Tue Feb 4 08:30:06 2003 @@ -152,6 +152,7 @@ (void)sigaction(SIGTERM, &saveterm, NULL); (void)sigaction(SIGTSTP, &savetstp, NULL); (void)sigaction(SIGTTIN,

In several places, openssh-2.9.9p2 passes a 'char' value to a ctype macro like 'isdigit'. This has undefined behavior on hosts with signed characters, if the character value happens to be negative. For example, isdigit('\200') expands to an array access that is a subscript error on hosts with signed characters where '\200' == -128. This leads to incorrect results,

This patch removes a lot of #include from files in openbsd-compat/ since "includes.h" is included prior to the others and therefore includes the headers first. Is it OK, or is it a design decision to have the includes specific to the c-files in the c-files as well? There is also the correction of an error. In openbsd-compat/readpassphrase.c there was #ifndef HAVE_READPASSPHRASE

http://bugzilla.mindrot.org/show_bug.cgi?id=314 Summary: switch to READPASSPHRASE_H to avoid conflicts with exiisting headers Product: Portable OpenSSH Version: -current Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: Build system

I'm getting a number of compiler warnings about type mismatches, building openssh-3.0.2p1 on HP-UX 10.20 with the HP ANSI C compiler. The resulting code seems to work, but spot-checking suggested that some of the warnings are the result of mixing int and u_int types, which might introduce subtle bugs. I figured it might be worth reporting, since I'm in the minority of people not

The idea behind this change is to add support for different "ssh-agents" being able to run at the same time. It does not change the current behaviour of the ssh-agent (which will set SSH_AUTH_SOCK just for itself). Neither does it change the behaviour of SSH_AGENT_PID (which still supports only one pid). The new implementation will go through the list of sockets (which are separated by a

In openssh_cvs/openbsd-compat: readpassphrase.c: In function `readpassphrase': readpassphrase.c:116: warning: operation on `ch' may be undefined The offending line is: ch = ch &= 0x7f; probably should be: ch &= 0x7f; In openssh-2.9p2: readpass.c: In function `read_passphrase': readpass.c:120: warning: passing

Hi, I'm sorry if this has already come up on the list, I did a quick search of the archive and didn't notice it. I noticed IMHO strange behavior in read_passphrase: If readpassphrase returns NULL and sets errno to ENOTTY, then read_passphrase returns an empty passphrase to the caller instead of error, now what happens with password authentication is that if readpassphrase fails every

FYI. Maybe ppl with access to Solaris can look at this. Niels. From: mark at salfrd.ac.uk (Mark Powell) Newsgroups: comp.security.ssh Subject: Re: openssh on a non-PAM system? Date: 6 Dec 1999 14:10:21 -0000 Message-ID: <82gg4d$15ta$1 at plato.salford.ac.uk> In article <x7zovrqhrv.fsf at bombadil.nic.net>, Dan Lowe <dan at bombadil.nic.net> wrote: >mark at salfrd.ac.uk

For those following the portable CVS tree.. I'd suggest holding off for a day or so unless you really want to get dirty. I just commited 32 patches from the OpenBSD tree, but have not worked out all the issues (due to Linux brain damage <sigh..Faster OpenBSD gets SMP..the happer I'll be>). The two things that need to be finished integrated in the configure.in is KRB5 and

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have just uploaded 1.2pre13 to http://violet.ibs.com.au/openssh/ Imporant changes: - - Fixes a single-byte buffer overrun in the PAM code. - - Quite a bit more Solaris support. EGD should work now (please test). - - Lots more autoconf options to enable Kerberos, AFS, TCP Wrappers and S/Key (all untested). - - MD5 passwords for Slackware Linux