similar to: scp and Solaris ACLs

Has anyone tried to build 3.1p1 on Solaris with the new openssl-0.9.6d? I am having trouble building; here is my setup: GNU ld, GNU make and my config options are as follows: ./configure --prefix=/usr/local/stow/openssh-3.1p1 \ --sysconfdir=/usr/local/etc --with-md5-passwords --disable-suid-ssh \ --with-ssl-dir=/usr/local/ssl Here is the error is fails on: /usr/local/bin/ld -o scp scp.o

I have an odd problem and I was wondering if anyone has ever run into this before. I have a machine running solaris 8, OpenSSH 3.1p1 and OpenSSL 0.9.6c and it has been working fine for quite some time (ssh that is). Today, /etc/system was updated to increase the maximum number of groups from 16 to 32. After the system was rebooted, things seemed to be working as expected, however one of our

has anyone had a problem building 3.1p1 with Solaris 8 (2/02 release)? That release of Solaris was the first (I believe) to incorporate their own /dev/random which OpenSSH 3.1 doesn't seem to like too much. When I run the configure, it reports that Random Number Source is set to use the rand-helper. If I use the ANDIrand Solaris package as my /dev/random, It configures properly (Random

Hi, I apparently was asleep at the wheel using scp, and accidentally copied a file onto itself. Scp generated an Input/Output error and did not perform the copy. However, now the file is corrupt. Is this a but? Is there anyway to fix the file I messed up? Thanks, Don Gathman 208.396.6675

http://bugzilla.mindrot.org/show_bug.cgi?id=485 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-06-04 23:28

If the source and destination file are identical, the receiving scp truncates the file. On the sending end, read() returns 0, and garbage is sent instead of actual data, and the receiving end puts it into the file, which at least confuses the users. -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/

Dear developers, I discovered that directories created by scp when recursive copying into a sgid directory do not inherit the sgid bit. I believe this is a bug. A patch to fix this is attached. Regards, Petr Skovron -------------- next part -------------- --- scp.c.orig 2005-10-11 16:50:17.000000000 +0200 +++ scp.c 2005-10-11 16:57:25.000000000 +0200 @@ -876,8 +876,12 @@

On Wed, 15 Jul 2020, Red Cricket wrote: > I have had this in my .bashrc for years: > > alias scp='rsync -avzP' Similar, though I named it rcp because nobody has the real rcp installed any more, but sometimes I need scp to connect to systems that lack rsync. https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=mksh/rcp;hb=HEAD >

Why can the local and remote paths be sanitized? Regards, Uri > On Jul 31, 2020, at 19:57, Ethan Rahn <ethan.rahn at gmail.com> wrote: > > ?I wanted to bring this up again due to: > https://github.com/cpandya2909/CVE-2020-15778/. This showcases a clear > issue with scp which it sounds like cannot be fixed without breaking scp. > This seems like it would lend some impetus

http://bugzilla.mindrot.org/show_bug.cgi?id=882 Summary: Scp cannot copy self-referring directories Product: Portable OpenSSH Version: 3.8p1 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: scp AssignedTo: openssh-bugs at mindrot.org ReportedBy:

Hi All, I am looking for SCP or RCP standards. I searched on the web but I am not able to find the standards. Please mail me the link where I can find the standards for SCP or RCP. Thanks, Abhijeet

Hello, For some time now, our users have been encountering a problem when using scp to overwrite files on our mass-storage system, which uses SGI's DMF product. I don't have any data as to whether or not any other HSMs would be similarly affected. The scenario is that a user is overwriting a file (via scp) that has previously been migrated to tape. The scp opens the file for writing, but

A while back someone posted a patch for scp that updates it to deal with files > 2gb by using 64 bit offsets as defined by LFS (Large File Sumit). I belive the patch was tested on Linux but maybe not on other systems that support largefiles. I've tried this under Solaris and scp fails with a broken pipe on only the second write to the pipe between scp and ssh if the file is over 2gb. If

http://bugzilla.mindrot.org/show_bug.cgi?id=828 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #588| |ok+ Flag| | --- Comment #2 from Damien Miller <djm at mindrot.org>

I was just curious how come there is no interactive option available for scp? A -i option is available for cp and rm, etc which prompts you before overwriting existing files. Was there a special reason why a similar option was not made available for scp? Thanks, Umar

I have not been able to get scp(1) to download a file with a newline in its name. I know that scp(1) requires that remote filenames be escaped for the shell, but that leads to protocol errors. I am also unable to get sftp(1) to handle such files. It fails with an ?unterminated quoted argument? error, no matter how I try to quote the newline. Furthermore, the SFTP CLI is not well-suited to

http://bugzilla.mindrot.org/show_bug.cgi?id=801 Summary: Improve usability of scp by adding a "make path" option Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: scp AssignedTo: openssh-bugs at mindrot.org

When you require a scp copy of more than 1 file to a destination that is not a directory, scp copy the last input file to the destination (version openssh-3.8.1p1). Thus if you forget to specify the destination, the last file is _silently destroyed_. I know that rcp exhibits the same behaviour but cp and rsync don't do anything in that case and _kindly_ warn you that you made a mistake:

This bug (Debian bug number 111692) occurs with filenames that have the character 0x0a in them (newline). This is how one repeats it: ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:15:50] $ : bash[592] ; cat > 'x x' This is a test. ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:17] $ : bash[593] ; scp 'x x' dorothee:ssh-test/

I've run into a situation where we'd like to replace rcp with rsync, but we've run into a difference in interface, which is causing us problems. Here's the problem. If we run this in rsync: > mkdir tmpdir; cd tmpdir > mkdir a; touch a/b > rsync -r a b/ > ls b a/ But for all the other programs, we get something different: > cp -r a c/ > ls c foo > cp