SFTP connection requires ssh daemon to have tunneled clear text passwords enabled

[axelu]

For SFTP connection it is necessary to enable tunneled clear text passwords via PasswordAuthentication yes in the ssh daemon (no is the default). Ideally that would not be the case. This was from Strongbox on iOS.

[mmcguill]

Another user had this issue also, really need to look into why the SFTP library in Strongbox requires this... Bumping

[cs-80]

@axelu Just curious what OS are you running for the ssd host?

@mmcguill thanks for taking a look at this. In my case I am running FreeBSD 11.3. Default configuration is: https://github.com/freebsd/freebsd/blob/master/crypto/openssh/sshd_config

[mmcguill]

I've been a little research on this, and I'm starting to wonder if it is possible at all to connect via SFTP with Username/Password without "PasswordAuthentication=YES".

Maybe someone with better sys admin/networking skills could tell me, but from my reading:

• It shouldn't be possible to use a username/password at all if this is NO

Would appreciate feedback from anyone with PasswordAuthentication=NO but still able to connect over SFTP with Username/Password - @axelu ?

[georgesnow]

If password auth is no. It would require a public key/private key pair. Or some other auto method.

Is the question of password authentication is set to off on the server can you provide password to connect?

[mmcguill]

Well the original question came from @axelu - who asked why he had to set:

PasswordAuthentication=YES

to use a username/password. As you can see from the title, the concern seems to have been about "Tunnelled Clear Text" passwords.

As it stands though now, I'm sort of thinking there's no way around this if you want to use a username/password based Auth.

[georgesnow]

Yes that would be the case. The password is being passed over the ssh tunnel with this type of setup.

https://superuser.com/questions/772748/tunnelled-clear-text-passwords-in-sshd#772765

[georgesnow]

Technically this is consider secure because it’s over ssh tunnel(rfp for sftp spec has more depth) the only other option is private public key pair

[mmcguill]

Ok, thanks very much @georgesnow - It's weird, I have a few people saying they can connect using only user/pw with this set to NO.

That doesn't seem possible. I found this which may be an explanation:

https://unix.stackexchange.com/questions/147504/can-use-password-authentication-with-sftp-even-though-passwordauthentication-no

It seems Filezilla is doing some voodoo and not actually using the user/pw but using the built in Mac ssh-agent which must have some cached/stored credentials (non user/pw).

[axelu]

@cs-80 Just curious what OS are you running for the ssd host?

It is not a question of the OS but of the SSH Server. The sshd host in my case runs openssh 7.9 server, there are other implementations for ssh servers like dropbear. For completeness purposes though, its running Gentoo Linux as the OS.

@mmcguill I am able to connect using username and password from other ssh clients and sftp clients even though PasswordAuthentication no. However, Strongbox on iOS requires it to be PasswordAuthentication yes.

Here are two further explanations, that actually provide the answer: https://superuser.com/a/374234 https://superuser.com/a/894625

So one is able to connect from other ssh/sftp clients even though the ssh server has PasswordAuthentication no, because the keybord-interactive authentication method kicks in, and as outlined in the simplest case is configured to ask for a password. That it allows that is configured by the ChallengeResponseAuthentication setting and the UsePAM setting. Here a debug

$ ssh -v user@host ... debug1: Authentications that can continue: publickey,password,keyboard-interactive ... debug1: Next authentication method: keyboard-interactive Password:

So the NMSSH library used in in Strongbox for the sftp connectivity must be implementing its auth method as password only and not by automating the keyboard-interactive method, so if the server comes back with its supported methods and it does not support password, the negotiation stops, respectively if the client sends that it only supports password auth method and it is disabled in the server, the negotiation stops.

I think I answered my own question and we are all good. Also, the password vs. the keyboard-interactive method does not transmit the password any differently to the server, so both are equally secure from that perspective. There is no action item here for @mmcguill anylonger to change anything based on that conclusion, other than documenting it for other future users, that the sshd host requires to support the password authentication method. I leave it up to @mmcguill to close this issue, or leave it open for the documentation change.

I learned something by looking at this again deeper this time.

[mmcguill]

I see, thanks very much @axelu @georgesnow

That's interesting. So, from a security point of view - Wouldn't the Keyboard Interactive also then the password in "Tunneled Clear Text"?

[georgesnow]

Yes. It’s just a matter of when the password is sent

[mmcguill]

Ok, great. I think the best way to tackle this is:

• to check the available authentication methods on connect
• If password is available then use that
• if not - need to add support for keyboard interactive and use that
• if neither password nor keyboard interactive available then message user about that

[georgesnow]

Would it be possible to support public keys?

[mmcguill]

That’s already supported

[georgesnow]

Woah haha must have been tired looked right past it.

[Mastermjr]

was able to login to sftp server and disable password auth with following config file:

Port 22

UseDNS no
UsePAM yes

PermitRootLogin no
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
AuthorizedKeysfile /mnt/root/authorized_keys
PasswordAuthentication no 
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
#AuthenticationMethods publickey password

# Force sftp and chroot jail
Subsystem sftp internal-sftp
ForceCommand internal-sftp
ChrootDirectory %h

FOR SSH version: OpenSSH_8.8p1, OpenSSL 1.1.1n 15 Mar 2022

I'm posting here because I had an issue in my sftp server logs when logging in via the strongbox app:
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

so as seen above I added the following line: PubkeyAcceptedKeyTypes=+ssh-rsa

hopefully this doesn't make the server super insecure, I don't think so since it should only accept my private key anyway, but it may be a good idea to update code to pass the actual key type of the private_key. Not sure if thats even possible, but would be great for docs on SFTP to add this as well, happy to help write up something if that helps make the docs easier to append to!

[Mastermjr]

I've been loving the PRO app btw, thanks for all the great work!!!

[strongbox-mark]

Hi @Mastermjr - I believe this is due to the libssh2 library we are using. We're still awaiting a public official release with updates for RFC8332. See here:

https://github.com/libssh2/libssh2/issues/536

This is to add support for the more modern ciphers which are accepted by OpenSSH. When an official release rolls out we'll add it to Strongbox and you should have no need for the +ssh_rsa key type in your config.

[strongbox-mark]

Hi @Mastermjr - With the release of 1.55.8 on iOS and 1.18.2 we've upgraded the SFTP libraries libssh2 to 1.10.0 and openssl to 1.1.1o.

Could you check to see if these remedy the issue? These new libraries should support better "key types" so you don't need to change the config PubkeyAcceptedKeyTypes.