|
Hi John,
Earlier you said the error was "timeout trying to connect". Now you
say the error message is "permission denied, please try again"
Those are two VERY different messages that mean VERY different things --
if you tell me you're getting a timeout error when you're really getting
an authentication error, you will send me looking in the wrong place.
You can't do password authentication ("keyboard-interactive") from a
5250 terminal. sftp is very fussy about when it will (or will not)
accept password authentication. It doesn't ever want a script to supply
a password, it considers that an egregious security hazard.
Unfortunately, it's a Unix program, and doesn't think that a 5250
terminal is an interactive terminal -- since 5250 isn't used on Unix
systems.
One solution is to run the SFTP via the 'expect' tool. Expect is a
scripting tool that emulates a Unix terminal, and "types" stuff in the
user's stead. It will bypass this limitation.
Another solution is to use a "real" unix terminal by connecting to your
PASE via xterm, Putty, or another similar tool.
I covered all of this stuff in the following article:
http://systeminetwork.com/article/ssh-scp-and-sftp-tools-openssh
John McKee wrote:
Finally had some time to revisit the sFTP issue.
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try pubkey: /home/BSYPGMR4/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,password
debug1: try pubkey: /home/BSYPGMR4/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: next auth method to try is password
debug2: readpassphrase: not a 5250 return ENOTTY
debug2: we sent a password packet, wait for reply
debug1: authentications that can continue: publickey,password
Permission denied, please try again.
I tried running this earlier this morning from my pc using cygwin. It
added an
entry to the known_hosts file. And, I was subsequently asked for password.
So, my assumption is that public/private key pair is not being used.
The above
snippet, running from QSH would seem to confirm that. And, since 5250 is not
supported, the next option would appear to be a batch job.
What I don't understand is why the person at the other site is under the
impression that public/private key is used in addition to user name/password -
while at the same time not knowing where the public key is stored on his
system.
I attempted FTP using SSL from System i (Is that the right name? Nobody around
here uses that - still AS/400.). I get no response and no details at
all. Just a timeout after a long time period. Is there some way to get
additional
information?
John McKee
Quoting John McKee <jmmckee@xxxxxxxxxxxxxx>:
Scott, I ran sftp with -vv, earlier. Don't know if I can try again yet
tonight
to capture the messages. Nut, the last two messages were:
connecting to.....
and some time later:
timeout trying to connect
I don't recall any other messages. Likely, tis will have to wait till
tomorrow
for me to get the full lo.
Chris:
I was using sftp from Qshell, as a client. I ran it first with
stricthostkeychecking=no to get the entry into the known_hosts file. The
person on the other end seemed clueless about his public key - as his
assertion
was that clients connected with FileZilla. It may be that the problem
is that I
need his public key. If that is the case, do you think FileZilla
stores that on
my pc where I can find it?
From your explanation of what is involved with FTP/SSL, it does sound
less messy
to use sFTP. I have contacted our corporate office and have been
assured that
port 22 is not blocked by the firewall.
So, anything else come to mind?
John McKee.
Quoting Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>:
Are you the client or the server?
FTP over SSL requires two ports, 21 for control and usually 20 when
behind a firewall.
Try passive mode for SSL.
Also most firewalls do not perform address fix up for FTP over SSL but
do take care of it for standard FTP. What address fix up is translating
the private IP behind the firewall to the public IP on the outside.
When a client requests passive mode, the server gives out its IP address
and port to make the data connection on and the firewall will see the
string and translate the IP address of the server to the Nat's IP
address.
When the client does not request passive mode, the server attempts to
connect to the client on the IP address and port that the client sends,
which does not work if the client is behind a firewall.
All this is why SSH is more popular. It uses one port, usually 22,
with the connection initiated by the clients. But depending on the SSH
client, you will need to import the Server's Digital Certificate. If
the client is an iSeries this involves the host sending you the public
cert and you using DCM to import it. (I like to use IE to SSHserver:22
to get the certificate so I can then put into DCM. Also if the server
is using a self generated certificate, you will have to get the root
cert into DCM. For testing I use Putty, a free download. It will allow
you to automatically add a server certificate to your PC.
So again are you the client or the server? If client, what client are
you using? If server, what server are you using and is it behind a
firewall?
Chris Bipes
Director of Information Services
CrossCheck, Inc.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee
Sent: Wednesday, February 25, 2009 5:40 PM
To: Midrange Systems Technical Discussion
Subject: sFTP issue
The problem:
A vendor wants data sent either via FTP/SSL or sFTP. Can't make a
connection
using either method.
HOWEVER, on a pc running FileZilla, the transfer works.
The contact I have tells me that everybody uses FileZilla. Really? He
knows
little about sftp - his words.
I do not understand why FileZilla works and sFTP won't. All I get is
that a
connection could not be made.
One other bit that probably makes the difference is that he site
requires both
key pair and username/password.
Ne has no idea how to get key pair working. I am wondering if that is
why sFTP
times out.
How would I be able to tell on myy end why FTP/SSL or sFTP do not
connect?
Thanks.
John McKee
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
