similar to: SRP unencumbered license statement

This is to announce the availability of SRP (Secure Remote Password) support for OpenSSH. A tarball is available on Tripod: http://members.tripod.com/professor_tom/archives/ http://members.tripod.com/professor_tom/archives/openssh-2.5.2p2-srp5.tar.gz (Note: Tripod requires you to LEFT click on links to download files.) To install, unpack, configure --with-srp, and make install, then create an

This is the 2nd beta release of SRP for OpenSSH. The patch attached to this message is relative to the current (20010411) CVS sources of OpenSSH-portable (2.5.4p1). A tarball is also available: http://members.tripod.com/professor_tom/archives/ http://members.tripod.com/professor_tom/archives/openssh-2.5.4p1-srp6.tar.gz (Note: Tripod requires you to LEFT click on links to download files, and

I have uploaded a new release of the OpenSSH (portable) SRP patch. This version is vs. the 20010625 openssh_cvs; there are no other changes. You can find it here: http://members.tripod.com/professor_tom/archives/ http://members.tripod.com/professor_tom/archives/OpenSSH-srp9.tar.bz2 http://members.tripod.com/professor_tom/archives/OpenSSH-srp9.patch.bz2 The tarball is the whole thing with the

For those of you who were following the discussion about the new draft and implementation of SRP-based password authentication in OpenSSH, I promised to have Stanford issue the IETF an official, explicit, statement reiterating the unencumbered royalty-free licensing terms. The new statement is now available from the IETF's IPR page. Tom

I noticed that (perhaps because ':' is invalid in a username) you can say ssh -l user:style host, where the "user:style" is sent by the client, and the server strips the ":style" part off and makes it available as part of the authentication context. It's currently unused. What are the plans for this, if any? I was experimenting with the idea of using it with SRP

Are there any plans to include support for SRP or a similar zero-knowledge password protocol into OpenSSH? -- Jeremy

In message <Pine.LNX.4.30.0104031615270.8678-100000 at holly.crl.go.jp>, Tom Holro yd writes: >SRP has different requirements from Diffie-Hellman. In particular, >for SRP the generator must be primitive. It turns out that the "primes" >file contains only safe primes with primitive generators, and is thus >ideal for SRP, but so far in OpenSSH it has only been used for

I just joined the list, and I see in the archives that about a month ago there was a brief discussion of SRP, but it was dismissed. I urge people to take a look at this site: http://srp.stanford.edu/srp/ It's very cool. Let's say I'm on vacation visiting a friend, and I want to log in to my account back home. I trust my friend's machine, but I don't have my home

G'day, First off, I'm not subscribed to the list, so if there are any responses that should be directed to me, feel free to CC me in :) The below url is an updated patch of Professor Tom's earlier SRP patches for SSH. The only things changed was so that it would compile on a newer openssh version. For more information regarding SRP, see http://srp.stanford.edu This isn't

Hello all Support for Secure Remote Password (SRP) for OpenSSH was last discussed in 2004: http://marc.info/?l=openssh-unix-dev&w=2&r=1&s=SRP&q=b There's a SRP patch for OpenSSL that's about 2 years in the making: http://rt.openssl.org/Ticket/Display.html?id=1794 Tom Wu from Stanford has been working on that. Has anything changed since 2004 that would make inclusion

>Simply stated, SRP is a strong password authentication protocol that >resists passive/active network attack, and when used in conjunction with >OpenSSH, solves the "unknown host key" problem without requiring host >key fingerprint verification or PKI deployment (e.g. X.509 certs). Put >another way, is there any good reason *not* to fold these patches into >OpenSSH

>From http://www.apache.org/info/20010519-hack.html: "The ssh client at SourceForge had been compromised to log outgoing names and passwords, so the cracker was thus able get a shell on apache.org." user's ssh --> SF's ssh --> apache.org's sshd So basically the user's password was entered in the clear to an untrusted program (SF's ssh). Never mind that

The latest snapshot (20020324) fails to compile here. Linux 2.4.18-rc1 Alpha The first messages are: monitor_wrap.c: In function `mm_request_receive': monitor_wrap.c:91: warning: int format, different type arg (arg 3) monitor_wrap.c:100: warning: int format, different type arg (arg 3) which have to do with fatal() calls and int not being the same as ssize_t... But the next one is the

Just wondering if there were any plans to integrate SRP support into OpenSSH. And if there aren't would a patch be accepted that would enable such. And if so could anyone give me a couple of pointers as to where the authentication code goes. Edward Flick

Dear members. I'm looking for best practice for administration Infiniband SRP volume with libvirt (virsh) How to manage these volumes? * SRP Disk is /dev/disk/by-id/scsi-2766f6c3030303037 or /dev/sdi Now I edited guest domain file with ``virsh edit XXXX'' command and append the following lines. <disk type='block' device='disk'>

[I know this is the 'port' list, but I can't find a better place to post this, and with the garbage going on @slashdot I figured I'd get this out. This belongs on sci.crypt or a general OpenSSH mailing list] First, a quick rehash of stuff everyone here already knows, OpenSSH can use two major forms of authentication: 1. Password 2. RSA keys The RSA method is good because it

All-- But it's not as simple as forwarding the password-based authentication. Regardless of what method was used to SSH from system one (user's) to system two (SF), the user then started up *a second* SSH session to go from two (SF) to three (Apache). There is no effective way for any authentication information from the first session to be passed to the second, in my mind. Remember

I've got an rsync job which is consistently failing, but I've been unable to diagnose the problem. FAQ/Google/docs/etc. checked and no luck. Basically, it looks like the rsync process invoked on the far end is exiting, and then the local process waits until the timeout and exits. Both systems are Sun boxes, Ultra 10 or better with 256+ MB of memory. Rsync version is 2.5.0 on the local

Crap. I hit send too fast. Last sentence in first paragraph should have read "no completely secure way" for authentication to be passed-- because the agent-based forwarding program could have been compromised as well--except for the cases already mentioned such as SRP and RSAAuth where the auth. information is better protected. Even if the SF server had been capable of forwarding the

The way things are now, input_userauth_request() calls the authmethod, and then does a bunch of checks, like the special case for root. If an authmethod requires a challenge-response conversation, these checks are skipped, unless they are duplicated by the authmethod. For example, in auth2-chall.c, some of the code is duplicated (logging, sending the reply), but the root special case is skipped.