After provisioning
Connect to Linux systems over SSH and to Windows Server over RDP.
This page explains how to connect after provisioning. It does not display actual addresses, usernames, or passwords.
Before connecting
After provisioning, sign in to the console and open the relevant machine’s details to find its connection address, username, and initial password. An order record alone does not provide connection credentials. Use the status and fields shown in the machine details.
If one account manages multiple machines, confirm the machine and installed operating system before using its credentials. Do not infer the connection address from the order number or guess the username based on the operating system. The address, username, and password must all belong to the same machine.
The panel on the right shows where each field appears, with blank values. Sign in to the console to view the actual details; they are not available in this illustration.
Use the connection address listed in the console. If multiple IPv4 addresses are listed, use the first.
Use the username and initial password for that machine; do not assume a generic username.
Change the password or configure key-based login. Verify the new login method before changing access rules.
Linux / FreeBSD / Proxmox VE
In a local SSH client, enter the address and username shown in the console, then enter the initial password when prompted. If the machine details list a connection port, use that value rather than the client’s default.
On first connection, you may be asked to verify the host identity. Confirm that it matches the target machine, and do not dismiss the warning if the address is unknown or the identity has changed unexpectedly. Password fields may not display characters as you type; this does not necessarily mean the input failed.
After signing in, change the initial password or configure key-based login according to your security policy. Keep the private key secure and add only the public key to the server. Open a second connection to verify the key works before closing the original session or changing authentication settings.
Allow firewall access only as required by your workload. After changing SSH listening settings, authentication methods, or inbound rules, keep the current session open and test a new connection. Do not close the existing session or remove the current access path before verifying the new one.
Logging in to a Proxmox VE host and logging in to a virtual machine are separate tasks. The credentials in this section are for the physical server. Configure virtual machine accounts and access separately when deploying each VM.
Windows Server
Open a local remote desktop client, enter the connection address listed in the console, and sign in with the username and initial password shown in the same machine’s details. If the client has saved credentials for another machine, check the username before connecting to avoid using an old account automatically.
If a certificate or identity warning appears, first confirm that the address matches the intended machine. For machines with multiple IPv4 addresses, use the first address in the list as the RDP destination. Do not substitute another address for the initial connection based on its intended use.
After signing in for the first time, change the administrator password and check remote access permissions and firewall rules. Update any old password saved in the local client. An existing session that still displays the desktop does not confirm that the new credentials work.
The Windows Server system language is the English, Traditional Chinese, or Simplified Chinese option selected at checkout. The remote desktop client’s interface language does not change the server’s system language. When entering a password, check the local keyboard layout and Caps Lock status.
Manage business software, account permissions, and data backups within the system. A successful connection provides administrative access; it does not mean that applications, additional addresses, or backup policies have been configured.
Address selection
Each machine includes one dedicated IPv4 address. If additional addresses are purchased, use the first address in the console list as the destination for both SSH and RDP.
Check the address order in the console, then enter the first address in your client. Do not use the numerical value, application binding order, or locally saved records to determine which address comes first.
When reporting a connection issue, note whether you used the first address in the list. This helps distinguish host access issues from additional address configuration problems.
After signing in, configure additional addresses in the operating system or virtual machines as needed. Receiving an additional address does not automatically configure application listeners, bridges, routes, or firewall rules.
If a virtual machine address cannot be reached, check the host connection and VM networking separately. Do not use a VM address in place of the physical server’s management address.
Before changing network settings, record the existing addresses and rules. After each change, test host management access and business traffic separately. A reachable website alone does not confirm that remote management is working.
Troubleshooting connection issues
Network misconfiguration and similar issues can prevent normal remote login. The console may provide a browser-based graphical session as a recovery option; availability depends on what is shown in the machine details. Use SSH and RDP for day-to-day management.
After restoring access, review the system settings that caused the interruption and test the usual connection methods again. A recovery session does not replace secure credential handling, careful review of network changes, or data backups, and it does not confirm that application services have recovered.
A client that cannot reach the destination, a failed account authentication, and an unavailable application after login are different issues. Record the exact step where the problem occurs, then troubleshoot accordingly instead of repeatedly changing unrelated settings.
Use the machine status and connection details returned by the console. If usable connection information is not available, do not guess the address or try a generic password.
Details for support requests
Submit technical support requests through a ticket in the console after signing in. Machine status and billing records are also available there. Before troubleshooting, confirm the machine and its associated order.
Identify the machine or order and the installed operating system. If multiple machines are involved, describe each separately; do not combine their addresses and errors in one report.
Say whether you used SSH or RDP, which client you used, and whether you connected to the first IPv4 address in the console list. You can also note whether the same issue occurs on another network.
Include the exact error text and the steps that led to it. Distinguish between a connection timeout, a refused connection, and an authentication failure. Redact passwords, private keys, and unrelated sensitive information from screenshots.
Note whether the password, network, firewall, or remote service settings changed before the issue began. Include the checks already performed to avoid repeating the same steps.
Do not paste a full password or private key into a support ticket. If console access is unavailable, contact support@amdssh.com to describe the account and access issue.
Check the address, username, and initial password, then choose SSH or RDP based on the operating system. If a connection fails, save the error details and submit a support ticket in the console.