Suppose my machine has a SSH daemon running. How do I get its fingerprint without having to create a network connection?
Meaning to say, without the use of ssh-keyscan.
Those keys (returned by ssh-keyscan), are detailed here, are in /etc/ssh/*.pub of the server.
So unless you have a program on the server ready to send them to you on its own, some kind of network connection would be required to fetch them.
Related
I've set up tailscale and connected to an exit node on my VPS on vultr.com. Predictably, I was kicked out and couldn't reconnect, as the VPS's public IP address has changed.
I can reboot the VPS and try again. What steps will I need to take? Does my VPS running behind an exit node even have a unique public address (which?), or does it need to be set up for something like port forwarding?
From looking at tailscale documentation, it looks like they came up with their own ssh, why? Why is the standard ssh inadequate for the purpose? I am not the admin of my tailscale network, and the admin is swamped right now. What can I do?
SSH uses TCP as transport and therefore requires the (srcaddr, srcport, dstaddr, dstport) tuple to be constant over the connection's lifetime.
I believe that since tailscale rotates connections dynamically, it is more suitable for use by clients than servers in a traditional client-server model, unless it provides an 'internal' virtual network over the distributed transport (which would kind of defeat the purpose of covering your tracks).
If you want to connect to your VPS over tailscale, you need to use their tools probably because of that. You can still connect directly to your VPS, though, through plain Internet, if it has any address of its own, and is not firewalled away (or similarly, NATed away). Your provider should either show you the address, or even better, provide access to out-of-band (like serial-port) command line access, where you can query the current addresses using commands like ip addr show.
In your Tailscale Admin console you should be able to see the machine's IP. Just use normal ssh and login that way.
So instead of ssh user#8.8.8.8 you'd do ssh user#100.64.0.1. Tailscale's own ssh client is useful if you want to hook deeper into their MagicDNS stuff, but it's not meant to be the only way to ssh into your machine.
If you run into errors, ping the machine you want to connect to (tailscale ping vps-machine-name). That should help you debug any tailscale client connection problems.
We have a system that implements reverse ssh tunnel to enable remote port forwarding.
This enables to expose devices on local network via a Public IP.
However, we're achieving this by a static port allocation, i.e. We've mapped Serial No.s of devices to Ports and each time a request comes to our server with Serial No. , we forward it to the designated port.
Obviously this design isn't scalable and we want to replace it with dynamic port allocation, such that the server itself takes care of allocating the port and freeing it once the device goes offline.
It'd be great to have suggestions on how this can be achieved.
Thanks in anticipation and apologies for my lack of knowledge in case I didn't explain it better (I'm new to this)
This can be solved by using a ssh command script in ~/.ssh/authorized_keys on your server.
command="reverse_server.py" ssh-rsa <publicKey>
First, a client has to connect to the script and send it's own serial (in my case a use the MAC-adress of one NIC).
The server looks into a database and tell the assigned port number or creates a new one for an unknown serial.
In the next step, the client can connect, using the reported port number as reverse port.
Btw. You should add some logic to monitor and recreate the tunnel if it disconnects or get stuck.
I am fairly new to ssh and still learning it. Recently I have made a tunnel connection with an ssh host and managed to successfully transfer data/files from my machine to the server with the command: scp file.extension user#hostIP:/directory/directory.
While this was successful, I am kinda struggling to reverse it, sending data/files from the server to the client. How would one go about completing that? Do I need to make some changes to ssh_config or just CLI commands are enough?
You need to change the order:
scp user#hostIP:/directory/directory file.extension
that's accomplishing the invert operation, off course, assuming that the address is correct, the file exists and you have the necessary privileges.
I installed redis on my computer and opened 1 redis-server and 2 redis-cli. If I type "shutdown save" command in the first redis-cli terminal, it will close both the server and the first redis-cli. Then, the second redis-cli won't be able to communicate with redis-server anymore because it has already been shutdown by the other redis-cli. It just doesn't make sense to me. IMO, a server is a standalone service and should always be running. A client should be able to connect/disconnect with a server but never disable a server. Why would Redis allow a client to disable a server which could be shared by many other clients? Consider if the redis server is on a remote machine and the redis clients are on other machines, wouldn't it be very dangerous since if one of the clients shut down the remote server then all other clients will be influenced?
If you don't want clients to execute the SHUTDOWN command (or any other for that matter), you can use the rename-command configuration directive.
As of the upcoming Redis v6, ACL are expected to provide a better degree of control over admin and application command.
No, I think you are getting it wrong. It's application responsibility to allow/disallow certain specific action on remote server. You can simply disallow certain commands so that single cli cannot take down the redis-server.
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.