that's what I thought Patrick... and this customer has MANY vendors they
work with in the product and every vendor is either SSH Key validated OR
password... but now they have a vendor that requires both.
So yes, both authentication methods have to happen.
Is that possible, from the IBM i client side.
for password auth I utilize the EXPECT script.... But really we don't need
to muddy the picture with that... Just need to know when we spawn the
sftp.. is there a way to tell the process we should authenticate both keys
and password?
here is the log when my customer tries using the password auth...
********************************************************************************
**** Start SFTP Log For HDBLUCARGO/2 on
2024-08-28-12.27.51.493000
********************************************************************************
spawn sftp -vvv -o PreferredAuthentications=password -oport=22 NRS@b
<NRS@xxxxxxxxxxxxxxxxxxxxxxxxxx>lah█
OpenSSH_8.6p1
debug1: Reading configuration data
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config█
debug3: kex names ok:
[diffie-hellman-group14-sha1
debug3: kex names ok:
[diffie-hellman-group14-sha1
debug3: kex names ok:
[diffie-hellman-group14-sha1
debug3: kex names ok:
[diffie-hellman-group14-sha1
debug3: kex names ok:
[diffie-hellman-group14-sha1
debug3: kex names ok:
[diffie-hellman-group14-sha256
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/SFTPUSER/.ssh/known_hosts'█
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/SFTPUSER/.ssh/known_hosts2'█
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling█
debug2: resolving "blah port 22█
debug3: ssh_connect_direct: entering█
debug1: Connecting to b <
http://transfer.test.bluecargo.io/>lah
[54.193.115.145]
port 22.█
debug3: set_sock_tos: set socket 3 IP_TOS 0x48█
debug1: Connection established.█
debug1: identity file /home/SFTPUSER/.ssh/id_rsa type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_rsa-cert type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_dsa type 1█
debug1: identity file /home/SFTPUSER/.ssh/id_dsa-cert type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ecdsa type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ecdsa-cert type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ecdsa_sk type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ecdsa_sk-cert type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ed25519 type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ed25519-cert type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ed25519_sk type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_ed25519_sk-cert type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_xmss type -1█
debug1: identity file /home/SFTPUSER/.ssh/id_xmss-cert type -1█
debug1: Local version string SSH-2.0-OpenSSH_8.6█
debug1: Remote protocol version
2.0
debug1: compat_banner: no match: AWS_SFTP_1.1█
debug2: fd 3 setting O_NONBLOCK█
debug1: Authenticating to blah22 <
http://transfer.test.bluecargo.io:22/> as
'NRS'█
debug3: record_hostkey: found key type RSA in file
/home/SFTPUSER/.ssh/known_hosts:70█
debug3: load_hostkeys_file: loaded 1 keys from b
<
http://transfer.test.bluecargo.io/>lah█
debug1: load_hostkeys: fopen /home/SFTPUSER/.ssh/known_hosts2: No such file
or directory█
debug1: load_hostkeys: fopen
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_known_hosts: No such file or
directory█
debug1: load_hostkeys: fopen
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_known_hosts2: No such file or
directory█
debug3: order_hostkeyalgs: prefer hostkeyalgs:
rsa-sha2-512-cert-v01@xxxxxxxxxxx
debug3: send packet: type 20█
debug1: SSH2_MSG_KEXINIT sent█
debug3: receive packet: type 20█
debug1: SSH2_MSG_KEXINIT received█
debug2: local client KEXINIT proposal█
debug2: KEX algorithms:
curve25519-sha256
debug2: host key algorithms: rsa-sha2-512-cert-v01@xxxxxxxxxxx
debug2: ciphers ctos: chacha20-poly1305@xxxxxxxxxxx
debug2: ciphers stoc: chacha20-poly1305@xxxxxxxxxxx
debug2: MACs ctos: umac-64-etm@xxxxxxxxxxx
debug2: MACs stoc: umac-64-etm@xxxxxxxxxxx
debug2: compression ctos:
none
debug2: compression stoc:
none
debug2: languages ctos: █
debug2: languages stoc: █
debug2: first_kex_follows 0 █
debug2: reserved 0 █
debug2: peer server KEXINIT proposal█
debug2: KEX algorithms:
ecdh-nistp384-kyber-768r3-sha384-d00@xxxxxxxxxxxxxxxxxxx
debug2: host key algorithms:
rsa-sha2-512
debug2: ciphers ctos: aes128-gcm@xxxxxxxxxxx
debug2: ciphers stoc: aes128-gcm@xxxxxxxxxxx
debug2: MACs ctos: hmac-sha2-256-etm@xxxxxxxxxxx
debug2: MACs stoc: hmac-sha2-256-etm@xxxxxxxxxxx
debug2: compression ctos:
none
debug2: compression stoc:
none
debug2: languages ctos: █
debug2: languages stoc: █
debug2: first_kex_follows 0 █
debug2: reserved 0 █
debug1: kex: algorithm: curve25519-sha256█
debug1: kex: host key algorithm: rsa-sha2-512█
debug1: kex: server->client cipher: aes128-ctr MAC:
hmac-sha2-256-etm@xxxxxxxxxxx compression: none█
debug1: kex: client->server cipher: aes128-ctr MAC:
hmac-sha2-256-etm@xxxxxxxxxxx compression: none█
debug3: send packet: type 30█
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY█
debug3: receive packet: type 31█
debug1: SSH2_MSG_KEX_ECDH_REPLY received█
debug1: Server host key: ssh-rsa
SHA256:IkhvpH/QI0Nbx+alNu0JIMCY33fWyVImIlP3my3R0HU█
debug3: record_hostkey: found key type RSA in file
/home/SFTPUSER/.ssh/known_hosts:70█
debug3: load_hostkeys_file: loaded 1 keys from b
<
http://transfer.test.bluecargo.io/>lah█
debug1: load_hostkeys: fopen /home/SFTPUSER/.ssh/known_hosts2: No such file
or directory█
debug1: load_hostkeys: fopen
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_known_hosts: No such file or
directory█
debug1: load_hostkeys: fopen
/QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_known_hosts2: No such file or
directory█
debug1: Host 'b <
http://transfer.test.bluecargo.io/>lah' is known and
matches the RSA host key.█
debug1: Found key in /home/SFTPUSER/.ssh/known_hosts:70█
debug3: send packet: type 21█
debug2: set_newkeys: mode 1█
debug1: rekey out after 4294967296 blocks█
debug1: SSH2_MSG_NEWKEYS sent█
debug1: expecting SSH2_MSG_NEWKEYS█
debug3: receive packet: type 21█
debug1: SSH2_MSG_NEWKEYS received█
debug2: set_newkeys: mode 0█
debug1: rekey in after 4294967296 blocks█
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_rsa █
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_dsa DSA
SHA256:VHIoEw0MbiS40qGc1y5PZsrzAUfllbeM13jY6hvwszc█
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_ecdsa █
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_ecdsa_sk █
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_ed25519 █
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_ed25519_sk █
debug1: Will attempt key: /home/SFTPUSER/.ssh/id_xmss █
debug2: pubkey_prepare: done█
debug3: send packet: type 5█
debug3: receive packet: type 7█
debug1: SSH2_MSG_EXT_INFO received█
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519
debug3: receive packet: type 6█
debug2: service_accept: ssh-userauth█
debug1: SSH2_MSG_SERVICE_ACCEPT received█
debug3: send packet: type 50█
debug3: receive packet: type 53█
debug3: input_userauth_banner: entering█
Welcome to the BlueCargo SFTP Server. Unauthorized access is prohibited.
debug3: receive packet: type 51█
debug1: Authentications that can continue: publickey█
debug3: start over
debug3: preferred password█
debug1: No more authentication methods to try.█
NRS@ <NRS@xxxxxxxxxxxxxxxxxxxxxxxxxx>blah Permission denied (publickey).█
█Connection closed.
Connection closed█
thanks
Jay
On Thu, Sep 5, 2024 at 10:30 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:
Hello Jay,
Am 05.09.2024 um 15:47 schrieb Jay Vaughn <jeffersonvaughn@xxxxxxxxx>:
I have written a MFT utility for the IBM i using all native methods.
I have provided the option of either ssh key or password authentication
but
not both.
Have a customer that has a need for both to happen.
When I allow password, I noticed I'm spawning with -o
PreferredAuthentications=password
I assert you don't need to pass any arguments.
If there is a usable authentication key found, it is used to do an
authentication try.
If not, ssh falls back to password auth — if the server allows it. If the
server only accepts key authentication, you should never reach the point of
fallback anyways, because key authentication succeeded.
:wq! PoC
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
midrange.com
