Re: SCP Issue (Can't open /dev/tty)

Thank you Scott for the response.

I believe removing the passphrase is what I would want to accomplish, but
I am unsure how to go about it.

I tried checking online and saw ssh-keygen command mentioned and leaving
the passphrase empty (for no passphrase).
I attempted to do that, but it doesn't seem to have changed anything. Is
it because there is still a passphrase it's just blank?

How would I actually remove the passphrase from the key then?


ssh-keygen -p
Enter file in which the key is (/home/QPGMR/.ssh/id_rsa):

Key has comment '/home/QPGMR/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase): Enter same passphrase
again:
Your identification has been saved with the new passphrase.
$

Russell Wesh, PMP | Data Integration Specialist
Sumitomo Drive Technologies
Sumitomo Machinery Corp. of America
Tel: +1-757-485-3355 ext. 8633
Cell: +1-757-822-4446
Fax: +1-757-485-7190
www.sumitomodrive.com | How are we doing?



From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>
Date: 09/04/2015 09:41 AM
Subject: Re: SCP Issue (Can't open /dev/tty)
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>



Russell,

The key you are attempting to use requires a passphrase, but it can't
ask you for the passphrase becuase you are not using a Unix-type
terminal, so it's not able to use that key.

You mention id_dsa... this is an older, less secure, key type that you
should not use. (Likewise, it mentions "identity", same problem.) This
is not a problem, as you can see that it is also trying id_rsa. You
need to fix the situation with id_rsa.

Use one of these alternatives:
1) remove the passphrase so that id_rsa can be used without it.
2) Use a Unix terminal (such as Putty) so that it can prompt you
3) Use something like ssh-agent to enter the passphrase
4) Use something like Expect to script the passphrase


On 9/4/2015 8:26 AM, RWesh@xxxxxxxxxxx wrote:

Good Morning

I am trying to utilize openSSH and SCP to transmit a file to one of our
suppliers (They request scp specifically).

I have been following Scott Klement's guide online entitled "Scripting

the

OpenSSH, SFTP, and SCP utilities on i" and while it has been extremely
helpful to get me started
I am still running into an issue I can't seem to solve.

Below is the debug of the command I am trying to run. I also have
(id_rsa.pub id_rsa known_hosts) in my .ssh directory for the user I am
running the command as
I notice that in the debug it attempts to use the private key under a
different name (Trying private key: /home/QPGMR/.ssh/id_dsa). Should I
rename my private key?

Any help would be appreciated

scp -v /home/Edegem/POout/UORDER USER@HOSTNAME:
Executing: program
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/openssh-4.7p1//bin/ssh
host HOSTNAME, user USER, command scp -v -t .
OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010
debug1: Reading configuration data
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/openss
h-4.7p1//etc/ssh_config
debug1: Connecting to HOSTNAME [IP] port 22.
debug1: Connection established.
debug1: identity file /home/QPGMR/.ssh/identity type -1
debug1: identity file /home/QPGMR/.ssh/id_rsa type 1
debug1: identity file /home/QPGMR/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version

Sun_SSH_1.1.6

debug1: no match: Sun_SSH_1.1.6
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'drserpapx' is known and matches the RSA host key.
debug1: Found key in /home/QPGMR/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
gssapi-keyex,gssapi-with-mic,publi
ckey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/QPGMR/.ssh/identity
debug1: Offering public key: /home/QPGMR/.ssh/id_rsa
debug1: Authentications that can continue:
gssapi-keyex,gssapi-with-mic,publi
ckey,password,keyboard-interactive
debug1: Trying private key: /home/QPGMR/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: VALUE FOR I:0
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: DONE
debug1: Authentications that can continue:
gssapi-keyex,gssapi-with-mic,publi
ckey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: VALUE FOR I:0
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: DONE
debug1: Authentications that can continue:
gssapi-keyex,gssapi-with-mic,publi
ckey,keyboard-interactive
debug1: VALUE FOR I:0
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: DONE
debug1: Authentications that can continue:
gssapi-keyex,gssapi-with-mic,publi
ckey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied
(gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactiv
e).
lost connection
$



Russell Wesh, PMP | Data Integration Specialist
Sumitomo Drive Technologies
Sumitomo Machinery Corp. of America
Tel: +1-757-485-3355 ext. 8633
Cell: +1-757-822-4446
Fax: +1-757-485-7190
www.sumitomodrive.com | How are we doing?



This document should only be read by those persons to whom it is

addressed and is not intended to be relied upon by any person without
subsequent written confirmation of its contents. Accordingly, Sumitomo
Machinery Corporation disclaims all responsibility and accept no liability
(including in negligence) for the consequences for any person acting, or
refraining from acting, on such information prior to the receipt by those
persons of subsequent written confirmation. If you have received this
e-mail message in error, please notify us immediately by telephone. Please
also destroy and delete the message from your computer. Any form of
reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message is strictly
prohibited.