I am learning ssh.
Assuming I try
userA#pc_A:~$ ssh userB#pc_B
which one is the server for ssh? pc_A? or pc_B?
And in the server machine, is only the sshd working at the communication above? I am confused when I read some different instructions. Thank you very much.
This is basic client/server terminology. You'll encounter this over and over with TCP/IP networking:
A server is a process that provides a service. It waits for clients to connect to it.
A client is a process that wants to use a service. It creates connections to a server.
userA#pc_A:~$ ssh userB#pc_B
In this case, the ssh program that you're running is a client. It will make a connection to a server running on host pc_B. That server may be an instance of the sshd program, but there are other ssh server programs that people can use.
If there is an sshd process running on pc_A, it's not involved with connections from an ssh client on A to a server on B.
The terms "sender" and "receiver" aren't really useful here. Once the client makes a connection to the server, the client and the server will communicate in both directions through the connection. So the client sends data which the server receives, and the server sends data which the client receives.
People will use the term "server" to refer to either the program (sshd) or the computer (pc_B) which provides the service. This can be confusing, and you will sometimes have to figure out by context whether they're talking about a computer or a program.
Related
I have a raspi machine behind NAT in my room, and I want to access it from the interenet using the URL.I found this article.
https://developers.cloudflare.com/cloudflare-one/tutorials/ssh
However, it required me to run the cloudflared program on the connecting client. I understand that this is for the security purpose. Does it possible to make the connect without running the cloudflared program on the client machine.
A follow-up question would be is it possible to ssh into ipv6 machine that using the same technique.
There are various options when it comes to connecting to a machine running on a private network:
Running cloudflared on the client (which you already found)
Installing the WARP client on the user side, then using cloudflared on the server side to expose the service securely. Finally, route the network traffic for the private network on the tunnel via WARP. This approach is described in a tutorial here
Cloudflare started also supporting in browser rendering of an SSH session. I have wrote a tutorial describing how to set it up here.
Approach (3) would do away with the need of running a client since it relies on a simple browser.
The question says it all. But to elaborate.
I have a oracle db running at some remote host. ip: 10.0.0.121 port: 1521
It can be accessed when I connect to a windows remote desktop machine.
Now how can I connect to this remote db from my local machine?
I believe that localtunnel is similar to telebit in that you get an encrypted https connection, not a plain tcp connection (which is good).
If I understand correctly, you'll want to use localtunnel (or telebit or perhaps even ngrok) on the windows machine to expose its database connection to the outside world. You'll want to use https (and absolutely not tcp or http which would leak database passwords and all your data) to create the tunnel.
Then you'll need to run something like sclient (or stunnel) on the computer that's doing the connecting to "unwrap" the https connection back to plain tcp. It might look like this:
sclient example.localtunnel.me:443 localhost:1521
In your database client or application you would then use localhost:1521 in your database connection string (not the https address).
This gives you the security of an encrypted connection and the convenience of exposing ports out to the world, all without adding any complexity to your application or client - you just run it as normal, connecting to localhost.
Comment if you need any additional clarification.
So, we all use TeamViewer for accessing GUI based (Windows / Linux) remotely and of course, it works really well.
Any ideas of how to do the same with headless (Ubuntu) servers? I'm thinking that the headless servers would run some sort of service that connects to a central server, which I can then remote into (somehow) and then route through the central server to the remote server.
It's kinda like the server based TightVNC that was popular a view years ago, where you could host the "server" module and have all your TightVNC clients connect to that server, whilst you do the same on your client, and the server module provides a gateway through to the remote systems. Just like TeamViewer really.
I wonder if the remote servers can connect to the (central) gateway server via SSH, I would do the same (again via SSH) but then the gateway server will provide me a "tunnel" through to the remote server.
I would of course prefer to have the remote servers have SSH ports opened through their firewall and then connect to them directly, but sometimes their IT teams don't like that. Having a server that runs a service, connects to a public server, means that the IT team will typically permit this, as the traffic is initiated internally and would be even more so agreeable to permitting it if that traffic uses an encrypted protocol.
Anyway - I just wondered if there was something out there that I could have a look at and see if it would work??
If you don't want a cloud controlled service (with serious security issues as of late), then check out the self-hostable MeshCentral project. It creates outbound tunnels that allow devices to communicate behind NAT and other networks.
Good news! Teamviewer 11 supports headless Linux servers :)
https://www.teamviewer.com/en/help/1111-How-do-I-install-TeamViewer-on-a-Linux-system-with-no-graphical-user-interface
Try https://www.dwservice.net/en/
Works on RPI, Linux and Windows.Best Part is free and Support for Terminal access
not just GUI ( so works faster in slower internet ) .
Client side- > just run the script ( not need of GUI)
Remote side - > Run just browser.
I discovered today that if I ssh-forward the local port X to ssh server port Y, and no process is listening on port Y, I can still connect to local port X (I don't get the usual "connection refused" error).
I did my test with 2 different SSH clients on a windows host connecting to a linux server.
After a bit of reflexion, I came to the conclusion that from a pure network point of view, this is the behaviour I should expect: the SSH client is actually listening on localhost:X, so the connection is possible.
Nevertheless, this leads to a problematic situation in which I have an apparently connected socket that talks to nobody. Even sending data on the socket is a successful operation.
So my question: does the SSH protocol manage this situation in some ways, i.e. do I have strategies for detecting this situation? And if yes, may I hope support for this feature on some SSH clients and APIs (today I'm using ssh.net, that does not seem to offer this feature).
If not, how would you proceed for detecting the situation? Timeout on answer?
Thanks for your help,
Alberto.
The only logical behavior would be to close client connection if the server can't connect to the remote side, but that would not be much better than just a hanging connection.
Also there can happen situation when the SSH server is waiting for the remote connection for a minute or two before giving up, so the client's connection will be opened for this period of time anyway.
So there's actually no logical alternative rather than a hanging client connection.
During my daily work, I need to use the customer's Database. for this connection, first of all, I need to connect the VPN to customer's network, and then make the DB connection.
Normally, if this connection can be established using TCP protocol. But sometimes I cannot connect to the DB. Then I track the network package, I found the connection is attempting connect to customer's DB using UDP protocol.
And now my network environment is using '172.16', if I change my network to '10.12', do the same connection, then change back to the '172.16' network, the connection can be established successfully.
Because the DB is in customer's side, I cannot check it.
The first couple of things I'd look at:
Firewall
... and ...
Firewall
PS:
Yesterday I had a case where the customer's database could communicate by Windows host name or by "localhost" ... but NOT by IP, nor by hostname alias ... even though the client and the SQL Server were ON THE SAME PC!!!!
Windows firewall was OFF. There wasn't any router between SQL server and the client (remember: same PC!).
But they installed a new A/V program ... that had it's own firewall ... and wouldn't allow any SQL Server connections.
PPS:
The correct approach, of course, is to configure firewall exceptions for all services you need (like MSSQL).
You could check with the customer's server administrator if the VPN access you have would have sufficient port/route access with customer's server database.
Normally VPN access allow outsider to gain access to internal network but it might be assigned by different router at the time you encountered problem. It isn't db problem, it is network issue.