Problems using sftp on HMC IBM system
Eduardo Otubo
I am having some problems using sftp to reach a HMC IBM system. The
connection is suddenly closed and I don't why. Actually I don't know
exactly how to read all these debug information. I would be very glad
with any help on this topic. Here is the full debug output provided from
the command execution:
otubo@phoenix ~ $ sftp -vvv hscroot@skiper
Connecting to skiper...
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/otubo/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to skiper [9.8.234.158] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/otubo/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/otubo/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/otubo/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 145/256
debug2: bits set: 506/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/otubo/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 99
debug3: check_host_in_hostfile: filename /home/otubo/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 61
debug1: Host 'skiper' is known and matches the RSA host key.
debug1: Found key in /home/otubo/.ssh/known_hosts:99
debug2: bits set: 511/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/otubo/.ssh/id_rsa (0xb960a030)
debug2: key: /home/otubo/.ssh/id_dsa ((nil))
debug1: Authentications that can continue:
publickey,gssapi-with-mic,gssapi,password,keyboard-interactive
debug3: start over, passed a different list
publickey,gssapi-with-mic,gssapi,password,keyboard-interactive
debug3: preferred
gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi
debug1: Next authentication method: gssapi
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/otubo/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,gssapi-with-mic,gssapi,password,keyboard-interactive
debug1: Trying private key: /home/otubo/.ssh/id_dsa
debug3: no such identity: /home/otubo/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).
debug2: fd 4 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env WINDOWID
debug3: Ignored env GTK_MODULES
debug3: Ignored env XTERM_SHELL
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env GNOME_KEYRING_SOCKET
debug3: Ignored env USERNAME
debug3: Ignored env PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env GDM_XSERVER_LOCATION
debug3: Ignored env PWD
debug3: Ignored env EDITOR
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env GNOME_KEYRING_PID
debug3: Ignored env GDM_LANG
debug3: Ignored env PS1
debug3: Ignored env GDMSESSION
debug3: Ignored env XTERM_LOCALE
debug3: Ignored env XTERM_VERSION
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env AWT_TOOLKIT
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env ZZPATH
debug3: Ignored env WINDOWPATH
debug3: Ignored env DISPLAY
debug3: Ignored env HISTTIMEFORMAT
debug3: Ignored env XAUTHORITY
debug3: Ignored env _
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug2: channel_input_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: fd 0 clearing O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 1808, received 1768 bytes, in 10.3 seconds
Bytes per second: sent 175.7, received 171.8
debug1: Exit status 1
Connection closed
[]'s
--
Eduardo Otubo
Software Engineer
Linux Technology Center
IBM Systems & Technology Group
Mobile: +55 19 8135 0885
eot...@linux.vnet.ibm.com
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Ben Lindstrom
A more useful thing to do is:
$ ssh hscroot@skiper /bin/true ## Use where your true bin is
located, on some it is /usr/bin/true
If you see any output other than the "Banner" output (if you use one,
which it doesn't look like it). You need to fix your shell to not
output data on non-interactive shell connections.
- Ben
> ripe...@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-
> sha1,uma...@openssh.com,hmac-ripemd160,hmac-
> ripe...@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
> debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
> hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
> cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se
> ,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
> cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se
> ,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ri...@openssh.com
> ,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ri...@openssh.com
William Adams
<ot...@linux.vnet.ibm.com> wrote:
> Hello friends,
>
> I am having some problems using sftp to reach a HMC IBM system. The
> connection is suddenly closed and I don't why. Actually I don't know exactly
> how to read all these debug information. I would be very glad with any help
> on this topic. Here is the full debug output provided from the command
> execution:
>
> otubo@phoenix ~ $ sftp -vvv hscroot@skiper
> Connection closed
>
It might be useful to examine the account, hcsroot, and the IBM SSH
configuration.
In particular, if this account is root, is root logon permitted?
Also, this IBM SSH installation appears to have the SFTP subsystem
helper enabled.
How is it configured?
Generally, the IBM SSH daemon and its helpers will place their stdout
and stderr in /tmp
or the like. The SSH daemon can be configured to put out some verbose
error messages
(just as the client can) which will show you why the connection is being closed.
Ben Lindstrom
On Sep 22, 2009, at 10:23 AM, Eduardo Otubo wrote:
> Ben Lindstrom wrote:
>>
>> A more useful thing to do is:
>>
>> $ ssh hscroot@skiper /bin/true ## Use where your true bin is
>> located, on some it is /usr/bin/true
>>
>> If you see any output other than the "Banner" output (if you use
>> one, which it doesn't look like it). You need to fix your shell to
>> not output data on non-interactive shell connections.
>>
>> - Ben
>
> I think we're dealing with a very restricted shell, look what I got:
>
> otubo@phoenix ~ $ ssh hscroot@skiper /bin/true
> Password:
> /bin/bash: /bin/true: restricted: cannot specify `/' in command names
> otubo@phoenix ~ $ ssh hscroot@skiper true
> Password:
> otubo@phoenix ~ $
> otubo@phoenix ~ $ ssh hscroot@skiper
> Password:
> Last login: Tue Sep 22 12:02:00 2009 from 9.18.200.68
> hscroot@hmc:~>
> hscroot@hmc:~> which true
> which: no true in (/hmcrbin/:/usr/hmcrbin)
>
> Any ideias?
> []'s
Make sure your sshd_config has:
Subsystem sftp internal-sftp
Otherwise I highly doubt it will work with a restricted shell. Since
sshd is pretty much doing $SHELL -c /path/to/sftp-server
- Ben
Eduardo Otubo
>
> A more useful thing to do is:
>
> $ ssh hscroot@skiper /bin/true ## Use where your true bin is located,
> on some it is /usr/bin/true
>
> If you see any output other than the "Banner" output (if you use one,
> which it doesn't look like it). You need to fix your shell to not
> output data on non-interactive shell connections.
>
> - Ben
I think we're dealing with a very restricted shell, look what I got:
otubo@phoenix ~ $ ssh hscroot@skiper /bin/true
Password:
/bin/bash: /bin/true: restricted: cannot specify `/' in command names
otubo@phoenix ~ $ ssh hscroot@skiper true
Password:
otubo@phoenix ~ $
otubo@phoenix ~ $ ssh hscroot@skiper
Password:
Last login: Tue Sep 22 12:02:00 2009 from 9.18.200.68
hscroot@hmc:~>
hscroot@hmc:~> which true
which: no true in (/hmcrbin/:/usr/hmcrbin)
Any ideias?
[]'s
--
Eduardo Otubo
Software Engineer
Linux Technology Center
IBM Systems & Technology Group
Mobile: +55 19 8135 0885
eot...@linux.vnet.ibm.com
_______________________________________________
Eduardo Otubo
>
> On Sep 22, 2009, at 10:23 AM, Eduardo Otubo wrote:
>
>>>
>>> A more useful thing to do is:
>>>
>>> $ ssh hscroot@skiper /bin/true ## Use where your true bin is
>>> located, on some it is /usr/bin/true
>>>
>>> If you see any output other than the "Banner" output (if you use
>>> one, which it doesn't look like it). You need to fix your shell to
>>> not output data on non-interactive shell connections.
>>>
>>> - Ben
>>
>> I think we're dealing with a very restricted shell, look what I got:
>>
>> otubo@phoenix ~ $ ssh hscroot@skiper /bin/true
>> Password:
>> /bin/bash: /bin/true: restricted: cannot specify `/' in command names
>> otubo@phoenix ~ $ ssh hscroot@skiper true
>> Password:
>> otubo@phoenix ~ $
>> otubo@phoenix ~ $ ssh hscroot@skiper
>> Password:
>> Last login: Tue Sep 22 12:02:00 2009 from 9.18.200.68
>> hscroot@hmc:~>
>> hscroot@hmc:~> which true
>> which: no true in (/hmcrbin/:/usr/hmcrbin)
>>
>> Any ideias?
>> []'s
>
>
> Subsystem sftp internal-sftp
>
> Otherwise I highly doubt it will work with a restricted shell. Since
> sshd is pretty much doing $SHELL -c /path/to/sftp-server
>
> - Ben
As I said in the other email, I can't change this configuration, as soon
as I solve I'll try this out too.
Thanks for the help.
Eduardo Otubo
>
> It might be useful to examine the account, hcsroot, and the IBM SSH
> configuration.
hscroot@hmc:~> cat /etc/passwd |grep hscroot
hscroot:x:500:500:HMC Super User:/home/hscroot:/bin/hmcbash
And the SSH configuration is here:
# $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
# Set this to 'yes' to enable support for the deprecated 'gssapi'
authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is
included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not
susceptible to.
GSSAPIEnableMITMAttack yes
# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords'
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
PermitUserEnvironment yes
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
Banner /opt/hsc/data/ssh/ssh_banner
LogLevel ERROR
In the end of the configuration file, there is a Subsystem that points
to a binary file that I could execute due to restrictions. And that
Banner file does not exists.
> In particular, if this account is root, is root logon permitted?
> Also, this IBM SSH installation appears to have the SFTP subsystem
> helper enabled.
> How is it configured?
This account is not root, then login is permitted.
The configuration is right up above.
>
> Generally, the IBM SSH daemon and its helpers will place their stdout
> and stderr in /tmp
> or the like. The SSH daemon can be configured to put out some verbose
> error messages
> (just as the client can) which will show you why the connection is being closed.
I just can't reconfigure the SSH daemon due to hscroot permissions, I'll
talk to the server owner to give me root's password to try those out.
Thanks for the help :)
William Adams
> LogLevel ERROR
This should be enough.
Depending on how syslogd on the IBM system is configured,
these three files should be of interest.
/tmp/sshd?.stdout.
/tmp/sshd?.stderr
and /tmp/log
The name of the last can be gleaned from the parameters passed to the
STC which starts syslogd.
the name of the first two should be in the STC which starts SSHD.
Not sure why your sshd_config has a BSD reference in it.
perhaps a hold over from the port of SSH to MVS(which I'm assuming this is).
the answer should be in the log created by syslogd.
Peter Stuge
> # override default of no subsystems
> Subsystem sftp /usr/lib/ssh/sftp-server
> Banner /opt/hsc/data/ssh/ssh_banner
> LogLevel ERROR
>
> In the end of the configuration file, there is a Subsystem that
> points to a binary file that I could execute due to restrictions.
If this sentence refers to /usr/lib/ssh/sftp-server then that
explains why you are unable to use sftp.
In order to use sftp, the user must have permission to execute
sftp-server as specified by the subsystem line, or the server
configuration must be changed, and /usr/lib/ssh/sftp-server above
replaced with internal-sftp
//Peter