Unable to connect to internal SQLServer from outside the company via SSH

I don't really understand the meaning of SSH... (do you mean port forward connection to SQL Server?), but there are two modes of authentication for SQL Server.

One is SQL Server authentication, which is the mode to connect as a "user registered with SQL Server".sa This is the form of a user who connects with a username and password in the connection string.

The other is Windows authentication, and if you use it, it would be easier to manage using Active Directory, but it is also available to local users of devices running SQL Server.
In this case, it is necessary to register user information by registering Active Directory groups, etc., or to register users who have added them locally as individual SQL Server users.
In this case, the connection string will be Integrated Security= True or Integrated Security= SSPI and will not specify a username or password because the connection will be "Windows User Permissions Running the Program".

In either case, the user's privileges to connect to SQL Server must be a minimum, plus the appropriate privileges to the target database.
Since sa is an administrator user of SQL Server, you have operational privileges on all user databases from the beginning, but you must grant permissions individually to the users you add.
If you only need to read and write data, I think it would be easy to give the db_datawriter/db_datareader role.

For additional permission relationships, please refer to the official documentation (https://docs.microsoft.com/ja-jp/sql/relational-databases/security/authentication-access/database-level-roles?view=sql-server-ver15.

--- Added 2022/4/29 ---

When connecting with port forward, of course you must change the connection string.
If SQL Server is based on a connection to the default instance, you must specify the "port number to be transferred to the remote side on the local host" to connect to the remote side number 1433.

For example, if you want to transfer -L11433:(SQL Server remote IP address):1433, the connection string must be "SQL Server is waiting at 11433 on the local host", so "Server=tcp:localhost,11433" is not a local instance, "

"Also, ""SQLServer DB operation is not possible."""" It says , but the fact that there are no actual error messages that you are receiving prevents you from resolving the problem.

This is
·No connection to SQL Server itself
·Connected to SQL Server but not authenticated
·Connect to SQL Server and authenticate, but lack of permissions
It's because I can't separate them at all.

The port forward of OpenSSH is only about connecting the local communication port to the remote communication port.No unconfigured communication will flow, and only the communication thrown to the local listening port that you turned to for forwarding purposes will fly remotely.
In other words, unlike the VPN connection, it does not "transmit all kinds of communication", so communication that occurs through AD authentication will not be established.(It's not possible to unilaterally allow a user to connect in the same capacity as he claims to be this user, even though he doesn't communicate properly.)I see)

In terms of development based on OpenSSH port forward operation, as Sayuri said, "Connecting with SQL Server users" is a realistic solution, and it's like, "If sa is enabled in the first place, isn't it okay to be a SQL Server user?"
In the case of Windows authentication only operation, sa users themselves cannot use it.

If such information is not presented properly, I don't think you can get an appropriate solution.(With this range of information, I don't think it's about disclosing the secrets of a particular business unless it's presented in a strange way.)