0

Today we needed to sFTP to a remote server. The remote server administrators didn't want us to send them the user's public key; instead, they asked the user to perform an initial connection, that was refused, then somehow "imported" the public key that had been "offered" during that connection.

How is this possible, and how could I achieve the same?

Note: the client version string is SSH-2.0-OpenSSH_6.9.
Note2: the remote software identifies itself as XFB.Gateway.
Note3: this method worked and our user is now able to access the sFTP server.
Note4: the issued command was sftp -v -o IdentityFile=my_id_rsa u0005fa@ip.

From what I know, I can only see fingerprints of the public keys. If someone had asked me, I would have answered the same as this other user wrote here. Does the key exchange work differently? Are clients transmitting their full public keys? In what phase?

In this other answer, a blog post is mentioned where someone describes creating their own custom Java ssh server software in order to capture clients' public keys. I tried it out, and it tells me:

john trying to authenticate with RSA MIIB..........

Now, from what I learned in this answer, MIIB would be the beginning of a 768 bit private key, while I was instead expecting to see a public key starting with AAAAB3NzaC1yc2E and corresponding to my test 2048 bit RSA private key. Is this just another format that can be converted to the ssh-rsa standard?

Are there other tools (possibly not Java-based) that accomplish the same task?

simlev
  • 1,105
  • 3
  • 14
  • 22
  • 3
    Did that actually work? The process they describe sounds horribly insecure. Nothing authenticated the connection! They just happen to trust that the first person to connect is the legitimate user. Hopefully nobody will discover this huge security hole. – Michael Hampton Mar 05 '19 at 15:57
  • @MichaelHampton Yes, to my disbelief it did actually work! Well, they did assign us a unique username and requested the connection attempt timestamp before "importing" the corresponding key. – simlev Mar 05 '19 at 16:29
  • I think ssh-agent does something like that when you do forwarding of identities – Marcel Mar 05 '19 at 16:38
  • Were they perhaps talking about simply using ssh-copy-id? – Eddie Dunn Mar 05 '19 at 17:47
  • @EddieDunn Of course not: it would have required an initial password login but we were provided no password at all. All we did was `sftp -v -o IdentityFile=my_id_rsa u0005fa@ip`. It failed, then subsequent logins were successful. – simlev Mar 06 '19 at 08:22
  • Maybe it was host based auth? Check this out: ```There are many ways of collecting the public key information from the client and getting it to the server. It can be copied using sftp(1), copied from ~/.ssh/known_hosts, or it can be grabbed using ssh-keyscan(1). Though the latter two only work if the client host also has an SSH server running. $ ssh-keyscan -t rsa client.example.org >> /etc/ssh/ssh_known_hosts ``` – Marcel Mar 06 '19 at 09:01
  • Above extract from here: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication – Marcel Mar 06 '19 at 09:01
  • @Marcel That is not the case here, since they have no way of accessing any of our SSH servers, which would not be using that specific key anyway. – simlev Mar 06 '19 at 10:44
  • In principle this would be easy to do. In practice I haven't found a way to do it with OpenSSH. If you set `LogLevel VERBOSE` in `sshd_config` it will log a SHA256 hash of all attempted public keys, both the failed and accepted keys. You could copy the key from the log to `authorized_keys`. Problem is I haven't found a way to get OpenSSH to log the public key without hashing it first, neither have I found a way to get it to accept a hashed version in `authorized_keys`, – kasperd Mar 06 '19 at 11:53
  • 1
    @kasperd Yes, I tried too and came to the conclusion that OpenSSH is unable to either log the full public key or trust a public key based on its SHA256 hash. – simlev Mar 06 '19 at 14:26

0 Answers0