server authorization with key and user/pass on windows

[masoudr]

Hi,
I wanted to run simple_server example with python3.4 on windows. The problem is crypt module does not exist on windows so I had to replace this line with another module in python:
return crypt.crypt(password, pw) == pw

I tried passlib module to first generate my hash password and then replace that line with:
return hash.des_crypt.encrypt(password,salt="JQ")==pw

and it got fixed.
Is there another way to authenticate a client? for example a key, not user/pass authorization.
Can you explain how to implement that?

I tried to run simple_client.py on this example but it throws the following error:
`SSH connection failed: [Errno 2] No such file or directory: 'C:\Users\Masoud\.ssh\known_hosts'

How to define user/pass or key on the client side?
Thanks.

[ronf]

What you did to use an alternate form of password hashing there looks good. You can use any method you like to store passwords, as long as you can provide a validate_password() callback which can perform an operation that returns whether a client-provided password is valid or not.

For an example of key-based authentication, take a look at the simple_keyed_server and simple_cert_server examples. You can either provide an authorized_client_keys argument to asyncssh.listen() or asyncssh.create_server() which contains the list of keys and/or certificate authorities to trust to sign keys, call set_authorized_keys from within the begin_auth callback to set a user-specific set of trusted public keys as shown in the example in simple_keyed_server, or you can provide callbacks similar to the password case (public_key_auth_supported and validate_public_key to do your own comparison of keys.

The different forms supported for passing in keys via authorized_client_keys and set_authorized_keys are described at http://asyncssh.readthedocs.io/en/latest/api.html#specifyingauthorizedkeys.

AsyncSSH supports the same options that OpenSSH does to limit when specific keys are valid, or what operations a client is allowed to perform if they log in using a given key. See the "AUTHORIZED_KEYS FILE FORMAT" section of the OpenSSH 'sshd' manual page if you want the full details about that.

[masoudr]

Thanks for the answer,
I followed this procedure:

1. Tried this link and generated the ssh_user_ca file and ca_key file and put it beside the simple_cert_server.py example (I generated those files in Ubuntu and put them back to Windows)
2. Then I put id_rsa private key file for my client (I'm using Bitvise ssh client app) and add it to my client key side.
3. I ran the example and server came up without a problem, but I can't connect to it in my client app it shows:
   Authentication failed. The key has been rejected. remaining authentication methods:"public key"
   and here is my start_server() part:

async def start_server():
    await asyncssh.listen('localhost', 22, server_host_keys=['ca_key'],
                          authorized_client_keys='ssh_user_ca',
                          process_factory=handle_client)
 

What I am missing?

[ronf]

Since you are trying to use certificate based authentication here, you'd need to copy not only the id_rsa file but also the id_rsa-cert.pub file to the SSH client. The client needs to send this certificate to the SSH server instead of the public key in id_rsa.pub when it authenticates for the server to be able to validate it against the "cert-authority" key in "ssh_user_ca".

[masoudr]

Still, I don't get it, my client app only accepts a private key file or a server public key and I tried to put id_rsa as private and id_rsa-cert.pub as host key (it gave me an error when tried to import id_rsa-cert.pub file).
Is there a client py example to test my server?

[ronf]

If you create a ".ssh" directory under your Windows home directory and add the id_rsa, id_rsa.pub, and id_rsa-cert.pub files into that directory, you should be able to use the "simple_client.py" example to do certificate-based authentication. You could also explicit specify the client keys to use with the client_keys argument to asyncssh.connect(). As long as you keep the id_rsa and id_rsa-cert.pub files in the same directory as one another, AsyncSSH should automatically find the certificate file when you specify the path to the 'id_rsa' file. You can also pass in a tuple containing both files:

client_keys=[('somepath/id_rsa', 'somepath/id_rsa-cert.pub')]

This shouldn't be necessary when you are following the filename conventions of the cert being the private key filename with '-cert.pub' added to the end.

[masoudr]

I tried to create the directory and put the files but It gave me permission denied error, then I used this code for simple_client:

import asyncio, asyncssh, sys

async def run_client():
    async with asyncssh.connect('localhost',client_keys=[('id_rsa', 'id_rsa-cert.pub')]) as conn:
        result = await conn.run('dir', check=True)
        print(result.stdout, end='')

try:
    asyncio.get_event_loop().run_until_complete(run_client())
except (OSError, asyncssh.Error) as exc:
    sys.exit('SSH connection failed: ' + str(exc))

SSH connection failed: [Errno 2] No such file or directory: 'C:\\Users\\Masoud\\.ssh\\known_hosts'
Then I tried to creatre known_hosts directory and this error happened:
SSH connection failed: [Errno 13] Permission denied: 'C:\\Users\\Masoud\\.ssh\\known_hosts'

[ronf]

The permission denied error is very odd, if in fact C:\Users\Masoud is your home directory. That error would suggest that you don't actually own this directory, or that somehow the permissions on it was set very strict even for you as owner, preventing you from creating new files and subdirectories there.

Can you confirm that C:\Users\Masoud exists, and see what permissions you have to it?

You can work around the error on known_hosts by setting "known_hosts=None" in the asyncssh.connect() call. This is not a good idea for an actual client, though, as it puts you at risk to a man-in-the-middle attack. You'll want to either fix permissions on your home directory or create a known_hosts file somewhere else and point AsyncSSH at that. Also, note that AsyncSSH won't automatically add entries to known_hosts. It expects you to do that manually or connect at least once with some other SSH client to populate the right entry there.

[masoudr]

As I know I'm using Windows 10 and my account user also has administrator rights and it is a normal admin user in windows. I don't have any restriction to writing files in any directory.
Currently, I'm using Python3.5.3 x64 and I installed the whole package again. I tried to set "known_hosts=None" and this error came up again:
SSH connection failed: Disconnect Error: Permission denied
I'm really getting confused. Is there any way to tell the client to look for keys on another directory not C:\Users\Masoud\.ssh?

[ronf]

Yes - absolute pathnames are supported in the filenames you put in client_keys. You can also use forward slashes instead of backslashes if you don't want to worry about remembering to double every backslash. If you don't put a full pathname, it will look for the files in the current working directory of whatever window you launched Python from.

The "Permission denied" error just means none of the authentication methods succeeded from within SSH. This is a different 'Permission denied' than the '[Errno 13] Permission denied' you saw before, which was an error related to file permissions in Windows.

If you want to try something simpler, you can put the 'id_rsa.pub' contents into what you specify as the authorized_client_keys file on the server side (without "cert-authority" in front of it) and import the 'id_rsa' on the client without the 'id_rsa-cert.pub' (allowing you to try Bitvise again). However, you need to be careful here -- trusting an individual key in authorized_client_keys will allow that key to be used to log in as any user if you provide a common authorized_client_keys in the asyncssh.listen() call. You'd need to follow the example in simple_keyed_server.py where you set a different authorized_keys file per user in the begin_auth() callback if you don't want that.

[ronf]

Closing this issue for now due to inactivity - please re-open it or open a new issue if you need more than the explanation above.