search for: guyverdh

I have been looking forward to the full PAM integration into OpenSSH for some time. I have been downloading many of the SNAP shots and testing them out on Solaris 5.8 and Solaris 5.9, and have been impressed with the improvements of late. One thing that I have noticed, however, is that when utilizing PAM -> UsePAM=Yes, that the password prompt reads Password: Now, I realize that this is

Hi Developers, This is Viet at Sun Microsystems. Does openssh support Solaris 10 spacrc, sol 10 x86, and sol 10 x64. If so, could you please point me to the link in openssh web site, not sunfreeware.com, that says so and the link to download. I need an official link to declare to Sun that you do support sol 10. Thanks.

>From the testing that I've done so far, using the command= restriction essentially ignores any and all attempts by the client to send different remote filenames, directory commands, etc... using scp -i some_key localfile remotehost:../../../../../../../../../../tmp/file places a copy of the file named "localfile" in the directory specified in the command= line of the

Hi All. OpenSSH 4.1 will be released in the next couple of weeks and we invite interested parties to test a snapshot. The changes since 4.0 are mostly bugfixes, for a detailed list see http://bugzilla.mindrot.org/show_bug.cgi?id=994 Running the regression tests supplied with Portable does not require installation and is a simply: $ ./configure && make tests Testing on suitable

We have a need to allow for encrypted file transfers around the internet, but do not wish to expose our systems completely. What we would like to see is either an extension to the scp / sftp code to use an sftp_config or scp_config type file that places restrictions on directory movement, upload locations, download locations, etc... Essentially run the sftp-server or scp code within a

Okay, I finally took the time to re-write the scripts that I had talked about a few threads earlier. I have 2 versions of them, and they currently work for Redhat Enterprise 4 and SuSE Enterprise 9. (using iptables, and xinetd.d) The 2 varieties are: #1 knock, to be allowed to connect from the IP address written by the knock sequence. This adds an iptable entry to allow the specified IP

Thanks to J.P. I now have a better understanding of how scp really works. I haven't uncovered any dark secrets, or unintended capabilities, I just prevented scp from sending the proper commands via ssh to the remote server. In essence, I gave scp a lobotomy or short-circuit. Either way, it's useful and gives me the desired effect. I don't know if anyone else would find this

>> I understand that that is not how scp works today.>And it will likely never change. Why not? Just because "That's how we've always not done it" doesn't sound like a very good reason to me. >> I'm suggesting that we make a minor change to how it works.>scp is maintained for compatibility reasons only, as I've understood>things. That's still

How difficult would it be to add an additional parameter to the -t that would *lock* the user at that directory level. say -T instead of -t... By locking, I mean translating /path/to/file as ./path/to/file, or ../../../path/../../../path/to/file as ./path/to/file. Basically set a root point as the current home directory, then build the pathing based on that, any "../" would become

Okay - We went around and around on the idea that adding an option to restrict scp to only allow files to be copied to a certain directory (or below) based on a different startup param. I was told to use all sorts of different options, parameters, methods, etc... All because no one wanted to modify the scp code, for whatever reasoning. I'm sitting here laughing right now, seriously