Tag Archives: ssh

[Solved] SSH connect error: permission denied, please try again

Permission denied, please try again. Error is reported as follows

When using SSH to log in to ECS (elastic compute server) Linux server, if you are the root user, even if you enter the password correctly, the following error messages will appear.

Permission denied, please try again.

The ssh server rejected the password. Please try again.

However, non-root users can log in normally, and root users can log in normally through the management terminal.

The reason for the problem is that the server SSH service is configured with the policy of prohibiting root user login.

If this parameter is not configured, or if the parameter value is set to Yes (default), root user login is allowed. Root user login will be blocked only when the displayed setting is No.

This parameter only affects the user’s SSH login, and does not affect the user’s login to the system through management terminal and other methods.

service sshd restart
restart sshd

Then try again.

[Solved] SSH Remote execute Python 3 error: Unicode encodeerror: ‘ASCII’ codec

background

Recently, the project requires SSH to execute Python code remotely on the centos7 container. The python version is 3.6. When opening a file with a Chinese name, there will be no problem executing Open ('wolf.TXT') locally on the centos7 container. However, after connecting through SSH, it is found that the open() method reports the following error:

UnicodeEncodeError :'ascii' codec can't encode characters in position 0-2

The problem occurs when opening.TXT (Chinese file name) is used as a parameter to encode according to the ASCII encoding method. We know that the ASCII encoding contains only 128 bits, including numbers, uppercase and lowercase letters and some special symbols, and does not contain Chinese characters. [this article will not introduce why encode is used]

Therefore, the code can run normally by making the following changes:

open('Wolf_is_coming.txt'.encode('utf8'))

Because here we specify the encoding format of UTF-8 (of course, it needs to be supported by the running environment).

Find out the essence of the problem, and then we can look at the SSH problem.

Language coding loop mirror

Python runtime container environment

In the python runtime environment container, use the locale and locale - a commands to view and discover the language coding environment, as shown below:

[root@pyrun-test-69d4d45d79-mqg6n /]# locale -a
C
en_US.utf8
POSIX
[root@pyrun-test-69d4d45d79-mqg6n /]# locale 
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

Language coding environment of SSH client

The language coding environment of SSH client is as follows:

root@coding-editor-test-8c6cdfdd8-9tpcl:/app# locale -a
C
C.UTF-8
POSIX
root@coding-editor-test-8c6cdfdd8-9tpcl:/app# locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

Configure language encoding environment

Through comparison, it is found that the coding environment of SSH client is c.utf-8, while the python running environment is en_US.utf8

(PS: C represents ASCII code, and en_us.utf8 and zh_cn.utf8 contain Chinese characters)

The first thought is that the SSH client may affect the default encode mode of Python runtime, so we set the SSH client environment to the same “here the client is Ubuntu” as the python runtime environment:

#!/bin/sh

# 1.set the language as en_US_UTF-8
echo -e 'LANG="en_US_UTF-8"\nLANGUAGE="en_US:en"' >> /etc/default/locale
# Effective Configuration
source /etc/default/locale

# 2.If the en_US_UTF-8 language pack is missing install the locales tool and set en_US_UTF-8
apt-get install --no-install-recommends -y locales
locale-gen en_US.UTF-8
localedef -v -c -i en_US -f UTF-8 en_US.UTF-8

After setting, try SSH to the python running environment container again. It is found that Open ('wolf.TXT') runs without any error.

So the question is, why does SSH run in the client’s coding environment

Research on SSH env mechanism

cat /etc/ssh/ssh_config 

The following contents are found in the SSH configuration file:

The above configuration will send the local locale sendenv to the python runtime environment, so we don’t need to ensure that the locale of the client and the python runtime environment are consistent.

You only need to modify the configuration to:

SendEnv LANG en_US.utf8

Mina SSH settings

Since the project is the code that Java calls the python running environment terminal through Mina SSH to execute, rather than SSH directly, The modification of /etc/SSH/SSH_config does not solve the problem.

Through the observation of Mina, it is found that parameters can be passed when creating a channelshell. The source code interface is as follows:

/**
 * Create a channel to start a shell using specific PTY settings and/or environment.
 *
 * @param  ptyConfig   The PTY configuration to use - if {@code null} then internal defaults are used
 * @param  env         Extra environment configuration to be transmitted to the server - ignored if
 *                     {@code null}/empty.
 * @return             The created {@link ChannelShell}
 * @throws IOException If failed to create the requested channel
 */
ChannelShell createShellChannel(
  PtyChannelConfigurationHolder ptyConfig, Map<String, ?> env)
  throws IOException;

When creating a channelshell, you can write this to configure the language coding:

shellChannel = session.createShellChannel(new PtyChannelConfiguration(), Map.of("LANG","en_US.utf8"));

[Solved] Gitlab can clone via SSH, cannot clone via HTTP, and cannot pipeline. Prompt port 80: connection rejected

Problem record: vm-ubuntu 20.04 used NAT mode to connect at the beginning, and later changed to bridge mode. After the change, the gitlab service originally started with docker could not be cloned. It always prompted: fatal… There was no remote library. It was not solved. Later, the mapped directory, container and image were deleted and a new container was restarted, After configuration, SSH cloning can be performed, but HTTP cloning cannot be performed. When performing gitlab CI pipeline, you will be prompted with failed to connect to 192.168.xx.83 port 80: connection rejected

By trying the command: git clone http://192.168.1.83/liutaiqiang/test.git Unable to clone hint: failed to connect to 192.168.xx.83 port 80: connection rejected

By trying the command: git clone   http://192.168.1.83:9001/liutaiqiang/test.git You can clone. Modify gitlab.yml under/SRV/gitlab/data/gitlab rails/etc, change port 80 to 9001, and restart gitlab service, which will change back to port 80

The problem is solved by modifying in the following ways

Custom port used

View the ID of the container

wmg@debian:~$ sudo docker ps
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                   PORTS                                                            NAMES
1132de0d1960        gitlab/gitlab-ce:latest   "/assets/wrapper"   19 hours ago        Up 2 minutes (healthy)   80/tcp, 443/tcp, 0.0.0.0:8081->8081/tcp, 0.0.0.0:10022->22/tcp   gitlab

Remember the container ID

In order to prevent accidents, stop the container and docker before operation

docker stop gitlab         
systemctl stop docker

We need to change the HTTP port to access 9001, and the address at the time of cloning is correct. The SSH port of gitlab is changed to 8022 of the host.

Modify host /Config.v2.json and hostconfig.json files under VaR/lib/docker/containers/container ID/

root@debian:~# cd /var/lib/docker/containers/1132de0d1960e1049a3f1f014b2ba215442a6c7f23f4983b324e055306822c52/
root@debian:/var/lib/docker/containers/1132de0d1960e1049a3f1f014b2ba215442a6c7f23f4983b324e055306822c52# ls
1132de0d1960e1049a3f1f014b2ba215442a6c7f23f4983b324e055306822c52-json.log  checkpoints  config.v2.json  hostconfig.json  hostname  hosts  mounts  resolv.conf  resolv.conf.hash

config.v2.json

hostconfig.json

Tips: if VIM editing is not formatted, the readability will be very poor. I copied the file locally and changed it with Notepad + +

Modify the gitlab configuration file/etc/gitlab/gitlab.rb in the container

Because I mapped/etc/gitlab to/backup/gitlab/config, I went directly to this directory to modify the gitlab.rb file, with the following parameters

external 'http://192.168.88.213:8081'
nginx['listen_port'] = 8081
gitlab_rails['gitlab_shell_ssh_port'] = 10022

After the change, just start the docker and container

systemctl start docker

docker start gitlab

SSH link encountered error [remote host identification has changed!]

When using vscode to connect to docker development environment, the following error occurred in SSH connection:

REMOTE HOST IDENTIFICATION HAS CHANGED!

At first, I thought that the environment sshd in docker was not started, or the host port was occupied, but after troubleshooting, no problem was found. Baidu later found a solution

Cause of problem:

ssh connection will store the public key in ~/.ssh/known_hosts, when connecting to the same host ssh will check the public key, if the public key is not the same then it will report an error, because
My development environment is in docker, and the host name is the same because of the mapped port, so I deleted the record of the host in the file and reconnected.
It's OK!

Solution:

Delete the information about the connected hosts in ~/.ssh/known_hosts and you're done!

SSH Error: write failed: broken pipe [Three Methods to Solve]

Problem scenario

Server environment: cloud Linux CentOS host

Client: Mac OSX terminal

Problem phenomenon

After connecting to the server with SSH command, if you do not operate for a period of time, you will not respond for a period of time when entering terminal again, and then an error prompt will appear:

Write failed: Broken pipe

You can only reconnect with the SSH command.

Solution:

Method 1: if you have multiple servers and do not want to set them on each server, just add the config file in the ~ /. SSH/folder of the client and add the following configuration:

ServerAliveInterval 60

Method 2: if you have more than one person managing the server, you don’t want to set it on each client, just set it on/etc/SSH/sshd of the server_ Add the following configuration to config:

ClientAliveInterval 60

Method 3: if you only want to keep the current SSH connected, you can use the following command:

$ ssh -o ServerAliveInterval=60 user@sshserver

Summary of SSH error reporting and solution records

SSH key signing failed

scenario: When Using SSH key to verify identity
error reported:

sign_and_send_pubkey: signing failed: agent refused operation

Environment: Debian 9.7 (Stretch)
Solution:

1) Confirm the problem

Add “SSH_AUTH_SOCK=0” before the SSH command:

SSH_AUTH_SOCK=0 ssh <username>@<server>

If you can log in normally, the variable SSH is displayed_AUTH_Output when sock content:

echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh

Then we can determine that the key signature failure is caused by the SSH agent with Gnome keying Gnome keying SSH agent does not always handle SSH keys in all formats correctly. However, it tries to process all SSH keys, resulting in an error( The typical one doesn’t have diamond and has to do this porcelain work)

If you still cannot log in normally, it means that SSH agent does not exist or exists but the key is not found. You can refer to here and solve it with a few commands

 

2) problem solving

As mentioned earlier, if SSH is added before the SSH command_AUTH_You can log in normally after sock = 0 , which means that the Gnome keying SSH agent is trying to process the SSH key encoding method that it may not be able to handle. There are two solutions: disable the Gnome keying SSH agent self startup, or use SSH keygen to regenerate and upload the public-private key pair generated by the coding method that Gnome keying SSH agent can handle

The second method is mentioned in this blog post. The advantage of this method is that it does not need to change the local system settings. The disadvantage is that it needs to update the public keys of all servers. For those who upload the public keys to multiple services (such as GitHub, gitlab, digitalocean, etc.), it needs to do a lot of repetitive operations, which is troublesome

The first method will change the system settings, but it is only a minimum change (only disable SSH agent startup under Gnome keying ), almost does not affect the system functions. Therefore, Gnome keying SSH agent can be completely replaced by SSH agent of openssh
the specific methods are as follows:

 

Open the search bar, search for startup applications applications and run them (if they are not installed, they will be prompted for installation)

In the pop-up window, find SSH key agent Gnome keying: SSH agent , and turn off auto start

Restart the system

SSH login error: no common Kex alg [How to Solve]

ssh login to solaris10 with error.

Jan 19 11:02:51 node1 sshd[7489]: fatal: no common kex alg: client ‘diffie-hellman-group1-sha1’, server ‘gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==’

This problem is caused by the ssh key, you need to regenerate the rsa and dsa key.

root@node1 :/etc/ssh #> ls -ltr
total 194
-rwxr–r–   1 root     sys          861 Jan 22  2005 ssh_config
-rwxr–r–   1 root     sys        88301 Jan 22  2005 moduli
-rwxr–r–   1 root     root         887 Nov  7  2010 ssh_host_rsa_key
-rwxr–r–   1 root     root         227 Nov  7  2010 ssh_host_rsa_key.pub
-rwxr–r–   1 root     root         668 Nov  7  2010 ssh_host_dsa_key
-rwxr–r–   1 root     root         607 Nov  7  2010 ssh_host_dsa_key.pub
-rwxr–r–   1 root     sys         5026 Nov  7  2010 sshd_config

Delete the original key
root@node1 :/etc/ssh #> rm -rf ssh_host_*

Generate a new key
root@node1 :/etc/ssh #> /lib/svc/method/sshd -c
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair

Restart ssh service
root@node1 :/etc/ssh #> svcadm restart ssh

 

Could not create directory ‘/ /. SSH’ when installing Git

Website content quality is poor, distribution efficiency is too low how to do?Huawei engineers offer 5 unique skills>>>

After installing git in window, generate SSH key in CMD. Use SSH keygen

During the command, I was prompted with the error of “could not create directory ‘/ /. SSH”. My colleague said that he had encountered the same error before, which was caused by the lack of system variables. At that time, he helped me add the variables, but I didn’t see which variable was added. Today, I looked up the information on the Internet and found out that the environment variable of home was added. My job is to add home = C/users. Then skills are generated automatically. Excerpt【

Digression: because it’s a Windows environment, it may have been affected when cygwin was installed a few days ago

In addition, in the actual use process, we found that although cygwin imitates the Linux environment under windows, in many cases, there will be obscure problems, and there is no error prompt. For example, this time, using the command line of cygwin and git, everything else is normal, but when submitting the code, it will lose its response (not stuck, but after entering, it will not submit the code and there is no output) and there is no error prompt. Finally, it’s done with the built-in CMD of windows

)】

In addition, the note I learned is the misunderstanding of GIT. I used to think that Git is GitHub, but I learned that they are different concepts through video learning. Git is actually more like a technology, and GitHub is a platform to provide the use of this technology

Environment: Windows 7 ultimate