'SSHServerConnectionOptions' object has no attribute 'server_factory' ????

[bowenerchen]

my code is:
server_ops: asyncssh.SSHServerConnectionOptions = asyncssh.SSHServerConnectionOptions(
server_factory = demo_ssh_server,
server_version = 'DEMO-TEST-AsyncSSH_2.13.1', # 自定义服务器 SSH 协议版本名称
server_host_keys = ['/xxxx/id_rsa'],
)
print(server_ops.server_factory)

and I got error:
AttributeError: 'SSHServerConnectionOptions' object has no attribute 'server_factory'. Did you mean: 'session_factory'?

In source code asyncssh/connection.py I got:
:param server_factory:
A callable which returns an :class:SSHServer object that will
be created for each new connection.

:type server_factory: callable returning :class:SSHServerConnection

conflicts???

my asyncssh version is 2.13.1
Python 3.11.3

[bowenerchen]

I have a few questions regarding the usage of the SSHServerConnectionOptions class while learning to use the asyncssh library:

1. How should the server_factory attribute of the SSHServerConnectionOptions class be used? In the documentation at https://asyncssh.readthedocs.io/en/latest/api.html#sshserverconnectionoptions, it is described as "returning SSHServerConnection", but in the source code, the description for this attribute has become "returns an :class:SSHServer object that will be created for each new connection."

2. When I create an SSHServerConnectionOptions object and try to access the server_factory attribute, I get an error: "AttributeError: 'SSHServerConnectionOptions' object has no attribute 'server_factory'. Did you mean: 'session_factory'?" Why is this happening? This attribute is clearly present in the SSHServerConnectionOptions class.

3. Do the server_factory in SSHServerConnectionOptions and the server_factory parameter in asyncssh.create_server have the same meaning?

[ronf]

Good catch! On the first issue you mention about the type of server_factory, the correct type is a callable that returns SSHServer, as it states in the "param" line. The later mention of SSHServerConnection in the "type" line is an error and should have matched the earlier text.

When it comes to the SSHConnectionOptions classes, it is not intended that applications EVER access member variables of these classes. The set of parameters you pass in as keyword arguments to create the options objects don't always match the names of the member variables of that class, and access to those member variables is meant only for the AsyncSSH code itself, and not applications. It's especially important that applications never change any of the member fields directly on an existing options object, as the parameters are often transformed at creation time of the options object. Once created, you should treat them as immutable. If you need to modify an option value, you should make a copy of an existing options object, specifying the fields you want to modify. You do this by passing in an "options" argument pointing at the object you want to start from, and then other keyword arguments for the values you want to change.

In the specific case of server_factory, this argument is actually assigned internally in the options objects as the member protocol_factory, which can come from client_factory for SSHClientConnectionOptions or server_factory for SSHServerConnectionOptions. It gets instantiated in connection_made in the SSHConnection class which is used for both client & server connections, and it becomes the owner value for these connections.

The server_factory in SSHServerConnectionOptions is the same as the one in asyncssh.create_server, and you can see examples of its use in the examples at https://asyncssh.readthedocs.io/en/latest/#server-examples as the MySSHServer class.

It actually looks like the client_factory argument in SSHClientConnectionOptions has the same error as server_factory. The "type" field there should say a callable returning SSHClient, not SSHClientConnection. I'll fix both of these references.

[bowenerchen]

Thank you for your answer, I understand now
I am currently trying to delve deeper into the SSH protocol and customized development of SSH services.
Aysncssh is a great framework, and I will continue to study it in depth! Thank you again.

[ronf]

Thanks - I'm glad you're finding it useful! If you have any other questions about it, feel free to ask...