I have a public/private key pair for ssh connections to a server S, but now, even if do a ssh to another device that does't need any key authentication, I always have the message:
> ssh user#192.168.0.10
Enter passphrase for key '/home/user/.ssh/id_dsa':
user#192.168.0.10's password:
Usually I hit enter in the first question (leaving it blank) and I type the user's password in the second question.
But as I want to write some scripts to automatize some things, the "Enter passphrase for key '/home/user/.ssh/id_dsa': " message bothers me.
Why it appears for every connection request? Can I do something so it won't ask me that for every connection? Just with the server S?
Thanks
Assuming you're using Linux ssh-agent to store your keys so you don't have to keep typing it.
Using ssh-agent to manage your keys
Based on this ServerFault answer:
ssh -o PubkeyAuthentication=no host.example.org
To avoid typing it every single time, you can add something like this to ~/.ssh/config
Host host.example.org
PubkeyAuthentication no
Related
I have created ssh keys and registered my public key on the target host under .ssh/.authorized_keys.
And it also generally works. I just observe a strange behavior: When I try to login the first time in the morning, I see "Server refused our key" and get forced to enter my passphrase. Any consecutive attempts then work fine and I see in the console output that it's registering with my key.
If I don't log in for a longer time, then a new login would show the same behavior as above and I get forced to enter my passphrase.
So I was wondering: Is there maybe a configurable value that prevents me registering with my key after certain time that I can just increase or deactivate?
You may find your answer here. Some servers are configured to verify the hosts before they can login for the first time.
https://unix.stackexchange.com/questions/42643/ssh-key-based-authentication-known-hosts-vs-authorized-keys
We can make SSH automatically write new host keys to the known_hosts file by setting StrictHostKeyChecking to “no” in the ~/.ssh/config file.
StrictHostKeyChecking=no
I have to configure hadoop cluster. For that it is required that all systems should be able to ssh each other in passwordless mode. Due to security, I have allowed only key based ssh (no password). There are 5 systems in cluster. I have to generated single key value pair. How to configure all other systems to use this key pair only such that they can ssh each other in passwordless mode.
I'm assuming you mean Linux machines.
There must be a ~/.ssh directory chmod 700 on each machine under the account that will originate or receive the connections.
The (private) key must be generated without a password.
Don't forget that by default weak (<2048 bit) keys are not accepted by ssh recently.
The following must be done to originate a connection.
Your private key must be placed in ~/.ssh/id_rsa or ~/.ssh/id_dsa as appropriate. You may use another name, but then it must be included on a -i option on the machine originating the request to explicitly indicate the private key.
Your private key must be chmod 600.
Now for allowing a machine to receive a request:
Your public key must be placed in a file called ~/.ssh/authorized_keys under the account that will receive the connections. You may place other keys that are allowed to connect via this account in here as well. A particularly tricky thing if you are in vi and pasting the key into the file from the paste buffer in PuTTY is that the key starts with a "ssh-". If you are not in insert mode, the first "s" will put vi in insert mode and the rest of the key will look just fine. But you'll be missing an "s" at the beginning of the key. It took days for me to find that.
I like to chmod 600 ~/.ssh/authorized_keys, but it's usually not required.
Now, you must have the host fingerprint added to the cache. Go to machine A, and ssh to machine B. The first time, you will get a query like "Do you want to add . . . to the host key cache?". This will stop your automated process very effectively. You have a few choices, which are up to your situation: a. manually ssh 20 times from each of 5 machines to the other 4 and say "yes". b. You could get the file called "known_hosts" (this is what ssh calls the "cache") and combine entries so that the same host_keys can be copied to all machines. c. You can put host fingerprints in /etc/ssh/ssh_known_hosts. d. Put the fingerprints in DNS (see man ssh). e. Just turn it off (NOT RECOMMENDED) by setting StrictHostKeyChecking in your ssh configuration.
I have created same ssh passphrase key from one main box to 10 servers, I want to deploy some commands and copy files from main box to other 10 servers with one time key. I don't want to use the passpharse key all time for logging on all servers.. i want to give key one time for on all servers..
Can anyone provide a small script or simplest method to accomplish?
[root#dasari9~] cat hostnames
localhost
remotehost
Sivaranjani
exlusive
[root#dasari9~]#
These all are hosts, I want to run some commands from main box to all above hosts.
If I understand the question correctly and you can connect to your hosts without being prompted, you can run a bash for loop:
for host in $(cat hostnames); do ssh $host <command to run>; scp <file to copy> $host:/path/to/target; done
After password-less ssh-login, is there any way in Linux to retrieve the identity of the remote-user that logged in?
I would like to take some different actions in the login-scripts,
depending on from which remote host/userid I do ssh-login.
The originating system's username is not recorded unless you use something like this answer - i.e. push the username as part of the connection. The remote host is encoded in the SSH_CLIENT environment variable, so that can be determined.
You could try to finger the remote system, but that requires fingerd to be running, which is not a common service these days.
You'll have better luck using specific keys for users, which can have options set at the start of the key such as environment="NAME=value" in the authorized_keys file to kind-of determine the remote user that connected. e.g.
environment="REMOTEUSER=fred" ssh-rsa <blahblahkey> <comment>
The use of the environment option in the key will only work if you've got PermitUserEnvironment set in the sshd config, otherwise the line in the authorized_keys gets ignored and you'll be prompted for a password.
I have been through some basics about setting up SSH tunneling via e.g., putty.
One question: how to let the two SSH ends authenticate each other based on certificate?
For example, using SSH tunneling for remote VNC access...
VNC == SSH (A) ===== SSH (B) === VNC
I want A and B to authenticate each other. It is arguable that VNC could have its own password for protection. But that is not the point here. I could have many apps running on A and B that are not necessarily having usr/pwd protection.
I check the putty config, seems no option for using certificate. Someone suggests stunnel, but I would like to see if doable using SSH directly. Thanks for the suggestion.
Any particular reason you need to use certificates, and not just ssh keys? The only reason I'm aware of is it takes the burden off of the host administrator from managing a complex configuration of authorized_keys files on hosts which have a lot of users who login.
OpenSSH introduced certificates in version 5.4, so make sure you're running at least that version on the server side. The client must support SSH certificates as well, and it is unclear to me at this moment if putty supports it. It does support ssh keys however, and unless you specifically need certificates, key-based authentication should be all you need.
Here is a good read on SSH certificates: http://blog.habets.pp.se/2011/07/OpenSSH-certificates
If you just need way to login without being prompted for a password, then just use ssh keys (which is what certificates use anyway).
You say this:
I want A and B to authenticate each other.
Whether you use keys or certificates, you get this already out of the ssh protocol itself. When the client connects to the server, it compares the host key to it's local known_hosts files. If it's the first time you've ever going to that server, it asks you if you want to accept it. If the server's key changed since you logged in, you get the Man-in-the-middle warning, and based on your client configuration, asks you whether it's OK to proceed or simply doesn't let you continue.
This is the process of the server authenticating itself to the client, which happens before the client attempts to authenticate to the server.
We are working on a solution that possess capability to perform SSH based authentication. please have a look at https://cecuring.com
Since we are gathering more users, you are free to submit new feature requests. we will collaborate with you in those cases.