Operating System - Tru64 Unix
cancel
Showing results for 
Search instead for 
Did you mean: 

sftp error on Tru64 V5.1B

D Vaughan
Occasional Advisor

sftp error on Tru64 V5.1B

I am getting the following error when I try to sftp from a system running Tru64 V5.1B using a regular account:

FATAL: ssh_pipe_create_and_fork() failed

sftp works using the root account. I think it is a permissions problem, but, have not been able to figure out what needs to change.

I have compared /etc/ssh2/ssh2_config and sshd2_config with another system that it works on and did not see any differences.

Any ideas on what I should check?
11 REPLIES
D Vaughan
Occasional Advisor

Re: sftp error on Tru64 V5.1B

some additional info:

# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Mon Oct 6 13:35:30 EDT 2008
#


output from sftp -v :

sftp -v xxx2
SshFileCopy/sshfilecopy.c:968: Making local connection.
SshFileXferClient/sshfilexferc.c:1234: ext_name `newline@vandyke.com', data:
00000000: 0a .
SshFileCopy/sshfilecopy.c:907: Connection to local, ready to serve requests.
Sftp2/sftp2.c:350: Connection ready.
SshReadLine/sshreadline.c:3388: Initializing ReadLine...
SshFileCopy/sshfilecopy.c:978: Connecting to remote host. (host = xxx2, user
= NULL, port = NULL)
argv[0] = /usr/bin/ssh2
argv[1] = -v
argv[2] = -x
argv[3] = -a
argv[4] = -o
argv[5] = passwordprompt %U@%H's password:
argv[6] = -o
argv[7] = authenticationnotify yes
argv[8] = xxx2
argv[9] = -s
argv[10] = sftp
SshReadLine/sshreadline.c:3454: Uninitializing ReadLine...
FATAL: ssh_pipe_create_and_fork() failed
Dennis Handly
Acclaimed Contributor

Re: sftp error on Tru64 V5.1B

>Any ideas on what I should check?

Could it be there is no space or too many process to fork another?
D Vaughan
Occasional Advisor

Re: sftp error on Tru64 V5.1B

space is not an issue and I am able to do a "ls -alR > /dev/null", put it in the background and then do other commands.
Steven Schweda
Honored Contributor

Re: sftp error on Tru64 V5.1B

> # sizer -v

Also potentially interesting:

/usr/sbin/dupatch -track -type patch_level | grep -i 'patch kit'

sftp -V

Around here, for example:

urtx# /usr/sbin/dupatch -track -type patch_level | grep -i 'patch kit'
Gathering details of relevant patch kits...
Patch Kit 5: T64V51BB26AS0005-20050502 OSF540
Patch Kit 6: T64V51BB27AS0006-20061208 OSF540
Patch Kit 7: T64V51BB28AS0007-20090312 OSF540

urtx# sftp -V
sftp: SSH Secure Shell Tru64 UNIX 3.2.0

And my debug output looks somewhat different
from yours (before yours dies). Talking to
itself, for example:

urtx# sftp -v urtx
SshFileCopy/sshfilecopy.c:696: Making local connection.
SshFileXferClient/sshfilexferc.c:1234: ext_name `newline@vandyke.com', data:
00000000: 0a .
SshFileCopy/sshfilecopy.c:635: Connection to local, ready to serve requests.
Sftp2/sftp2.c:420: Connection ready.
SshReadLine/sshreadline.c:3388: Initializing ReadLine...
SshFileCopy/sshfilecopy.c:706: Connecting to remote host. (host = urtx, user = N
ULL, port = NULL)
argv[0] = /usr/bin/ssh2
argv[1] = -v
argv[2] = -x
argv[3] = -a
argv[4] = -opasswordprompt=%U@%H's password:
argv[5] = -oauthenticationnotify=yes
argv[6] = urtx
argv[7] = -s
argv[8] = sftp
debug: SshConfig/sshconfig.c:2804: Version not found on first line, assuming con
figuration to be old style.
debug: SshConfig/sshconfig.c:651: Setting variable 'VerboseMode' to 'FALSE'.
debug: SshConfig/sshconfig.c:2746: Unable to open /root/.ssh2/ssh2_config
debug: Connecting to urtx, port 22... (SOCKS not used)
debug: Ssh2/ssh2.c:2349: Entering event loop.
[...]


> Could it be there is no space or too many
> process to fork another?

That's the sort of thing I'd look for, unless
the SSH software is obsolete.

A Google search for the error message found
a VMS TCPIP problem where the 127.0.0.0
network was not on the allowed network list.
There is that suspicious "Making local
connection" message in the debug output which
lets me dream that this might not be totally
irrelevant. Do you have TCP wrappers
software installed (about which I know
nothing), whose hosts.allow and/or hosts.deny
stuff might be interfering here?
D Vaughan
Occasional Advisor

Re: sftp error on Tru64 V5.1B

# /usr/sbin/dupatch -track -type patch_level | grep -i 'patch kit'
Gathering details of relevant patch kits...
Patch Kit 6: T64V51BB27AS0006-20061208 OSF540
#
# sftp -V
sftp: SSH Secure Shell Tru64 UNIX 3.2.0
#


we aren't using tcpwrappers

sftp works when I'm logged in as root. That's why I was thinking permissions or config
Steven Schweda
Honored Contributor

Re: sftp error on Tru64 V5.1B

> [...] That's why I was thinking permissions
> or config

Plausible.

> argv[0] = /usr/bin/ssh2

That would seem to be what it's preparing to
run just before it pukes, so you might look
at that. Around here:

urtx# ls -ld / /usr /usr/ssh /usr/ssh/bin /usr/ssh/bin/ssh2 /usr/ssh/bin/sftp2
drwxr-xr-x 27 root system 8192 Mar 20 2009 /
drwxr-xr-x 32 root system 8192 Oct 16 2007 /usr
drwxr-xr-x 5 root system 8192 Oct 16 2007 /usr/ssh
drwxr-xr-x 2 root system 8192 Mar 20 2009 /usr/ssh/bin
-rwxr-xr-x 1 bin bin 1211968 Jul 9 2008 /usr/ssh/bin/sftp2
-rwxr-xr-x 1 bin bin 1993120 Jul 9 2008 /usr/ssh/bin/ssh2

And everything else in /usr/ssh/bin looks
the same, except:

-rws--x--x 1 root system 1621728 Jul 9 2008 ssh-signer2


Around here as a non-root user:

urtx> sftp -v urtx
SshFileCopy/sshfilecopy.c:696: Making local connection.
SshFileXferClient/sshfilexferc.c:1234: ext_name `newline@vandyke.com', data:
00000000: 0a .
SshFileCopy/sshfilecopy.c:635: Connection to local, ready to serve requests.
Sftp2/sftp2.c:420: Connection ready.
SshReadLine/sshreadline.c:3388: Initializing ReadLine...
SshFileCopy/sshfilecopy.c:706: Connecting to remote host. (host = urtx, user = NULL, port = NULL)
argv[0] = /usr/bin/ssh2
argv[1] = -v
argv[2] = -x
argv[3] = -a
argv[4] = -opasswordprompt=%U@%H's password:
argv[5] = -oauthenticationnotify=yes
argv[6] = urtx
argv[7] = -s
argv[8] = sftp
debug: SshConfig/sshconfig.c:2804: Version not found on first line, assuming configuration to be old style.
debug: SshConfig/sshconfig.c:651: Setting variable 'VerboseMode' to 'FALSE'.
debug: SshConfig/sshconfig.c:2746: Unable to open /usr/users/sms/.ssh2/ssh2_config
debug: Connecting to urtx, port 22... (SOCKS not used)
debug: Ssh2/ssh2.c:2349: Entering event loop.
debug: Ssh2Client/sshclient.c:1456: Creating transport protocol.
debug: SshAuthMethodClient/sshauthmethodc.c:95: Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:95: Added "password" to usable methods.
[...]
D Vaughan
Occasional Advisor

Re: sftp error on Tru64 V5.1B

ownership/permissions look OK.

mfgprd1> ls -ld / /usr /usr/ssh /usr/ssh/bin /usr/ssh/bin/ssh2 /usr/ssh/bin/sft
p2
drwxr-xr-x 43 root system 16384 Jun 24 09:52 /
drwxr-xr-x 29 root system 8192 Jan 21 2009 /usr
drwxr-xr-x 5 root system 8192 Aug 15 2002 /usr/ssh
drwxr-xr-x 2 root system 8192 Oct 1 2008 /usr/ssh/bin
-rwxr-xr-x 1 bin bin 1203776 Nov 22 2006 /usr/ssh/bin/sftp2
-rwxr-xr-x 1 bin bin 1993120 Nov 22 2006 /usr/ssh/bin/ssh2
mfgprd1>
Steven Schweda
Honored Contributor

Re: sftp error on Tru64 V5.1B

> ownership/permissions look OK.

Well, it was worth a try.

I continue to be troubled by your (debug)
argument vector looking different from mine
("argv[4] = -o", ...), which suggests that
we're really running significantly different
stuff. Might be that last Patch Kit 7 (but I
know nothing).

Might be permissions on some obscure run-time
library, too, I suppose. You might try to
see what /usr/bin/ssh2 uses.

> [...] a regular account [...]

All non-root accounts have the same problem?

My idea supply seems to be running low.
D Vaughan
Occasional Advisor

Re: sftp error on Tru64 V5.1B

Steven,

Thank you for your help so far.

When I try ssh2 I get a similar error:


$ ssh2 -v mfgdev2
debug: SshAppCommon/sshappcommon.c:185: Allocating global SshRegex context.
ssh2: FATAL: pipe: Permission denied
$

D Vaughan
Occasional Advisor

Re: sftp error on Tru64 V5.1B

a co-worker figured it out.
The permissions on /dev/streams/pipe were set to 644 and needed to be 666
Steven Schweda
Honored Contributor

Re: sftp error on Tru64 V5.1B

> The permissions on /dev/streams/pipe were
> set to 644 and needed to be 666

That's fairly obscure. Around here:

urtx# ls -ld /dev/streams /dev/streams/*
drwxr-xr-x 3 root system 8192 Oct 16 2007 /dev/streams
crw-rw---- 1 root system 32, 66 Nov 16 2006 /dev/streams/dlb
crw-rw-rw- 1 root system 32, 56 Jan 27 2006 /dev/streams/echo
crw-rw-rw- 2 root system 32, 49 Jan 27 2006 /dev/streams/kinfo
crw-rw-rw- 1 root system 32, 5 Jan 27 2006 /dev/streams/lat
crw-rw-rw- 1 root system 32, 54 Jan 27 2006 /dev/streams/log
crw-rw-rw- 1 root system 32, 55 Jan 27 2006 /dev/streams/nuls
crw-rw-rw- 1 root system 32, 58 Jan 27 2006 /dev/streams/pipe
crw-rw-rw- 1 root system 32, 52 Jan 27 2006 /dev/streams/ppp
crw-rw-rw- 1 root system 32, 53 Jan 27 2006 /dev/streams/strkinfo
drwxr-xr-x 2 root system 8192 Oct 16 2007 /dev/streams/xtiso