A machine on this Wi-Fi is running sshd. You know that much. You do not know whether it came up as .41 or .57 today. The laptop with the address written down is at the office.
There are two separate problems in that sentence. Finding the service is one. Deciding that the thing answering is the machine you meant is the other. Dotori SSH Terminal keeps them apart, because conflating them is how people get hurt.
Finding the service is a narrow question
On a /24, there are 254 host addresses. Test the chosen port on each and list the ones that accept a TCP connection. The app does this on the current Wi-Fi, with port 22 as the default and any other port on request.
An open port is a candidate. It is not proof that the service is SSH. A closed port is not proof of absence either. The host may be asleep, filtered, on another VLAN, or out of reach.
Direct connection stays available regardless. Enter a hostname or IP address and a port and connect, with no scan first. Discovery and connection are separate paths, so one being unavailable never blocks the other.
A handoff carries coordinates, not secrets
Dotori WiFi Scanner can open this app with the target already filled in. What travels between them is deliberately thin:
- host and port — yes
- username and password — never
The credential prompt belongs to the SSH app, and it opens after the target is selected. That keeps passwords out of deep links, browser history, logs, and another app's storage.
Saved credentials are optional. They live in the app's protected storage, keyed by host and port. They can be removed one target at a time. This version supports password authentication; private keys are not yet supported.
Trust on first use starts after the connection
Passwords and host keys answer different questions. A password proves the user to the server. The host key helps the user recognise the server. Discovery has no opinion on either.
On a first connection the app shows the key type and SHA-256 fingerprint. It asks whether to remember it. Compare that value against one from the server administrator before accepting it.
Later connections with a matching fingerprint proceed quietly. A different fingerprint gets a prominent warning, and it should. A reinstall or a key rotation produces exactly that change. So does interception.
The app will not replace a saved fingerprint silently. Verify the new key through a trusted channel first. Treat this as a server-identity question, never a discovery glitch.
In the terminal
Commands run on the connected host. There is no proxy server in between and no developer backend anywhere in the path.
A bar of Ctrl, Alt, arrow, and function keys sits within reach. Those are the keys a phone keyboard handles worst. Theme, terminal text size, and interface language are explicit settings.
Close the session when the work is done, particularly before changing networks.
Discovery results, credentials, and terminal output are not sent to the developer or to the ads SDK. The remote server still controls command history, permissions, and audit logging — as it should.
When nothing appears
- Confirm the SSH service is running and listening on the port being scanned.
- Check that the phone and the server are on the same reachable network, with no client isolation or VLAN between them.
- Try a direct connection with a known address, since that path is independent.
- Check the server firewall, and whether it admits the phone's subnet.
SSH grants command execution on another machine. Use it only on systems and networks you own or are authorised to administer.
Wrap-up
A port scan narrows a subnet to a short list. The host key decides whether the machine answering is yours. Keeping those two steps distinct is the whole design. It is also why a handoff never carries a password.
Worth setting up before the next time a device changes address on you.
Top comments (1)
把“发现服务”和“验证主机”拆成两件事，这点讲得很清楚，很多人确实会把端口通了就当成连对了。补充一个小做法：首次连接前先在服务端本机用 ssh-keygen -lf 看一下主机密钥指纹，再跟应用里显示的 SHA-256 指纹逐字比对，这样 TOFU 才有实际意义。另外端口开放只是候选，抓一下 banner 确认是 SSH 协议再连会更稳妥。