When we using powershell remoting we have many prerequisite as compared to remoting through ssh command. So, I just want to know that if we can do remoting through ssh command why powershell remoting come into existence?
Prerequisite:
Configure WinRM
Use WSMan protocol
Allows the client to have full network connectivity to that address
Related
My SSH configuration for Azure pipeline worked fine until I upgraded ubuntu from Ubuntu20 to Ubuntu 22. Now I get this message:
##[error]Failed to connect to the remote machine. Verify the SSH service connection details. Error: Error: All configured authentication methods failed.
How can I debug this? I can ssh to my server using my ssh key without any issues.
Is there a way for me to know more about the issue and debug it?
Also, there is this announcement on Azure pipeline that says:
Azure DevOps proceeds in rollout of changes to permanently disable communication over TLS 1.0, TLS 1.1 and weak cipher suites of TLS 1.2. If your tools are dependent on legacy TLS for communication with Azure DevOps, please take necessary actions to enable TLS 1.2, as detailed in the blog.
Could this be related?
All help is highly appreciated.
This solution work for me.
key type ssh-rsa not in PubkeyAcceptedAlgorithms
which lead to a solution by adding,
PubkeyAcceptedKeyTypes=+ssh-rsa
in /etc/ssh/sshd_config and restarting sshd.
Seems newer Ubuntu 22.04 has changed default accepted key types and this plugin no longer worked despite SSH command working fine.
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.
My java application connects to an SSH server and runs a third party utility by ChannelExec of Jsch. Then, this application makes unsecured/uncompresed file transfer to another server on which an SSH server is installed.
The flow is:
JavaApplicationHost --> SSHServer1(3rd party utility runs) --> SSHServer2
I want file transfers between these SSH servers to be secured/compressed. But, I cannot use any platform dependent utilities such as ssh command. I cannot install anything on these SSH servers. I just can use JSch to these SSH servers.
Is there a way to secure/compress communication between these SSH servers by JSch or any other alternatives ?
Thanks in advance!
There is a jump host example of Jsch at http://www.jcraft.com/jsch/examples/JumpHosts.java.html that cascades multiple JSch sessions.
The flow can be:
JavaApplicationHost --(JSchSession1)--> SSHServer1(3rd party utility runs) --(JSchSession2)--> SSHServer2
If I can create another tunnel by JSchSession2 between these SSH servers, I will be able to secure/compress the 3rd party application.
I will test and update here.
Thanks!
I have a microservice, let's call it RdsConnector, I want to test locally that is normally deployed on a machine on AWS. It connects to a MySQL instance, which is also in AWS, without any SSH tunnelling as they are in the same VPC. To connect to that MySQL instance from my local machine, I can use SSH tunnelling to get into the VPC I have set up in AWS. This is what that configuration looks like:
I could set up my microservice to also connect through SSH (optionally, perhaps), but I don't want to do that. Then I would have a different configuration running it locally vs in the cloud. What I want to do instead is set up some kind of proxy server on my local machine that will take the SSH credentials and do that SSH tunnelling, exposing the VPC MySQL endpoint locally. Then RdsConnector will just use that local endpoint, and I won't have to have a different config for RdsConnector just for local testing.
I'm not very familiar with the networking technologies in use here. I just know that there's no public IPs for my VPC, so I have to SSH in. I imagine that what I want is possible, but I have no idea what the moving parts would be.
Ok this turned out to be quite simple actually! The ssh program can do this for you, this is how I configure it with Mac OS ssh:
ssh -N -i "/Users/foo/aws_ssh_key.pem" \
-L "localhost:5990:stack-name-vpc-db.asdfqwerty.us-east-1.rds.amazonaws.com:3306" \
foo#12.34.567.890
With the -L flag, it'll proxy stuff over the SSH connection for you from the given endpoint to the provided endpoint on the other side. That -N flag is optional, it just turns off the regular SSH console since we only want to run a proxy server. The microservice can treat localhost:5990 as if it were the regular MySQL endpoint.
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.