New answers tagged

2

You have got some wrong record in /etc/ssh/ssh_known_hosts as the log proposes. How did you set up that one? It is system wide alternative to ~/.ssh/known_hosts and should be used only in reasonable situations (distribution, local network, certificates). Check what is in that file, check for some inconsistencies and possibly if there is your server1 or ip ...


1

You can also have a host who's memory is so badly fragmented that it can't allocate a page a contiguous memory to fork the process for hosting an SSH session. In such a case, you can get either of the messages: ssh_exchange_identification: read: Connection reset by peer or: Connection closed by aaa.bbb.ccc.ddd depending on how far the host gets ...


0

I recently needed this but none of the options above worked, ssh -v showed that the command-line options passed via the -o switch were over-ridden by the values specified in my ~/.ssh/config file. What worked was this: ssh -F /dev/null <username>@<host> From the ssh man page: -F configfile Specifies an alternative per-user ...


3

Maybe you are not looking for the correct permission set. Have you tried to temporarily disabled SELinux, if you can? In the server you are trying to access console: # setenforce 0 And try to access again. If it works, is a SELinux related problem. Then if you want to solve the problem get the correct permissions. First take a look at the ACL of ...


1

You are trying to authenticate to user smpadmin and you show us the permissions of ~user/.ssh (at least according to owner/group). The directory ~/.ssh should be owned by the owner of the home directory, as all the other files inside. You copied it from different user and didn't change owner or you are connecting to wrong user.


0

If you tailf /var/log/auth.log on the server and login again, you should see the reason for the failure get logged. If not, kick up the verbosity in the SSH daemon config file to DEBUG and retry again. Often times it's related to file permissions.


0

Run ssh with verbose mode (add as many -v as you need) and try to find out the reason. For example ssh -vvv user@host You will get a debug output that helps you to find out the reason.


2

First generate the key-pair on your Ubuntu machine. After, copy the contents of the generated .pub file in your ssh folder (~/.ssh/id_rsa) and paste it to the username/.ssh/id_rsaauthorized_keys file, on a new line, on your CentOS for the specific user you are logging in with.


3

The Policy is simply a basic aid to tidying up and checking the incoming certificate signing requests follow corporate policy (or more precisely, your organisation's Certificate Policy (CP) and/or Certification Practice Statement (CPS)). If you are signing your certificates on the command line, the security benefits are negligible - after all, you (or ...



Top 50 recent answers are included