SSH with multiple virtual machins - amazon-ec2

I'm currently on amazon's aws, what I'm trying to do is to create two virtual machines, the first is the master VM named "master" and the second is the slave VM named "node1".
I would like to run a program on the VM master for tasks to be distributed on the slave machine. If everything works fine, i would like to create several slaves and create a parallelism system.
On amazon aws, to connect to virtual machines we must use a xxx.pem file generated by the aws to identify myself by ssh -i "xxx.pem" xxx#xxx
But in my case I created a "master" user in the master VM and then generated a blank password by doing ssh-keygen -t rsa. I copied and pasted on a "authorized_keys" file on the /home/node1/.ssh/ of the slave VM that i created myself.
Now when I try to do an ssh node1#xxx.xxx.xxx.xxx he asks me for a password... i dont understand why ?
After trying everything i can't connect with ssh name#private_ip , he asked me an password each time.
What should i do ?
Thanks in advance !

Server side log :
debug2: load_server_config: filename /etc/ssh/sshd_config
/etc/ssh/sshd_config: Permission denied
[ec2-user#ip-172-31-35-17 ~]$ sudo su
[root#ip-172-31-35-17 ec2-user]# /usr/sbin/sshd -D -p 8022 -ddd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 728
debug2: parse_server_config: config /etc/ssh/sshd_config len 728
debug3: /etc/ssh/sshd_config:22 setting HostKey /etc/ssh/ssh_host_rsa_key
debug3: /etc/ssh/sshd_config:24 setting HostKey /etc/ssh/ssh_host_ecdsa_key
debug3: /etc/ssh/sshd_config:25 setting HostKey /etc/ssh/ssh_host_ed25519_key
debug3: /etc/ssh/sshd_config:32 setting SyslogFacility AUTHPRIV
debug3: /etc/ssh/sshd_config:40 setting PermitRootLogin forced-commands-only
debug3: /etc/ssh/sshd_config:49 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /etc/ssh/sshd_config:65 setting PasswordAuthentication no
debug3: /etc/ssh/sshd_config:70 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:97 setting UsePAM yes
debug3: /etc/ssh/sshd_config:102 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:107 setting PrintLastLog yes
debug3: /etc/ssh/sshd_config:110 setting UsePrivilegeSeparation sandbox
debug3: /etc/ssh/sshd_config:127 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
debug3: /etc/ssh/sshd_config:128 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
debug3: /etc/ssh/sshd_config:129 setting AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
debug3: /etc/ssh/sshd_config:130 setting AcceptEnv XMODIFIERS
debug3: /etc/ssh/sshd_config:133 setting Subsystem sftp /usr/libexec/openssh/sftp-server
debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: private host key #0: ssh-rsa SHA256:sHblS+34MhcBEtE/kCxfAoJ1fcZJyu4tYZKdcDEeQ4E
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:BLgYMx1fFNlmkUpwqdp61g98k+ojM2TV2L1KYPmYdao
debug1: private host key #2: ssh-ed25519 SHA256:/SXACNF7WrrjPDcCsxFYX6Km9jfyAtA0pisg6VFxxIM
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-D'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='8022'
debug1: rexec_argv[4]='-ddd'
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 8022 on 0.0.0.0.
Server listening on 0.0.0.0 port 8022.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 8022 on ::.
Server listening on :: port 8022.

Related

Password Authentication only denied OpenSS?

Specifically to only using PasswordAuthentication to make a connection. I know there are many posts with regards to public key permission denied. With remote SSH connection attempt:
sshd PC UserName#staticIP : Permission denied (publickey,
keyboard-interactive)
root#staticIP : Permission denied (publickey,
keyboard-interactive)
I have a windows PC behind a (public) router which has a static IP assigned to it. For now I just want to get an initial ssh connection before moving to key authentication. I am not getting a password prompt:
Settings sshd_config:
PermitRootLogin yes
PubkeyAuthentication no
PasswordAuthentication yes
Logging yes
LogLevel VERBOSE
On the public router with static IP:
SSH and port 22 is allowed on my router, inbound and outbound.
I get no log message in my router's Firewall Log when trying to ssh in.
I have port forwarding on, for port 22 to the PC where I have the
sshd running.
sshd PC: Firewall has inbound rule allowed for port 22 SSH. The "Allow apps to communicate through Windows Defender Firewall" is allso allowed on Private and Public for both OpenSSH Server and OpenSSH SSH Server.
HrPing is successful: hrping staticIP -p 22 -n 4 -l 1000
Using PowerShell as administrator as well as from an Ubuntu PC I have tried:
ssh sshd PC UserName#staticIP -p 22
ssh root#staticIP -p 22
On the sshd/Server PC > Services > OpenSSH SSH Server > Log On: should that be selected as Local System Account or This account - and the you select a user?
In ProgramData > SSH > Logs:
10952 2022-06-15 16:36:18.724 Connection from 102.250.4.93 port 12692 on <Local LAN IP address sshd PC> port 22
10952 2022-06-15 16:36:18.987 Connection reset by authenticating user <UserName> 102.250.4.93 port 12692 [preauth]
I get no messages in windows eventViewer under OpenSSH. There are no key's at either the client or sshd PC. With the initial connection attempt, the sshd PC's fingerprint is copied over to the client's known_hosts folder, but that also ends in permission denied.
PS C:\users\myUser\.ssh> ssh UserName#staticIP -p 22 -v
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to staticIP [staticIP] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\myUser/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\myUser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.1
debug1: match: OpenSSH_for_Windows_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to staticIP:22 as 'UserName'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:gYkCT81kmqzhDjEIFipnAl2N8ZjtrF3WwOeIKYBQy98
debug1: Host 'staticIP' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\myUser/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\myUser/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\myUser/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\myUser/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\myUser/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\myUser/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\myUser/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\myUser/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\myUser/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\myUser/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\myUser/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
UserName#staticIP: Permission denied (publickey,keyboard-interactive).
sshd_config file:
# $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/bin:/usr/sbin:/sbin:/usr/bin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/id_ed25519
# Ciphers and keying
#RekeyLimit default none
#Logging yes
#SyslogFacility AUTH
#LogLevel VERBOSE
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication no
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
#AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
#UsePAM no
#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /etc/ssh/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
You can see from the debug output
debug1: Authentications that can continue: publickey,keyboard-interactive
and from the final error message
Permission denied (publickey, keyboard-interactive)
That the server is not accepting password authentication method (otherwise the word password would've been included in the list).
If you have set PasswordAuthentication to yes by yourself then make sure to restart the ssh service in order for the changes to take effect.

Asking for password when pushing to gitea with ssh

I have just set up my own gitea service on the Ubuntu server (the server is run with user gitea). The following steps have been done:
generate ssh key on my windows pc, and store at C:\Users<user_name>\.ssh, namely id_rsa_gitea and id_rsa_gitea.pub
copy and set the public key on my gitea account setting page
There are existing key files for my GitHub account in the directory, namely id_rsa and id_rsa.pub. I modified the file config in the same directory as
Host github.com
HostName github.com
User git
IdentityFile C:/Users/<user_name>/.ssh/id_rsa
IdentitiesOnly yes
Host 192.168.200.101
HostName 192.168.200.101
User gitea
IdentityFile C:/Users/<user_name>/.ssh/id_rsa_gitea
IdentitiesOnly yes
Pushing to GitHub works fine. But when I try to push to gitea, it gets
$ git push -u origin master
gitea#192.168.200.101's password:
Permission denied, please try again.
gitea#192.168.200.101's password:
Permission denied, please try again.
gitea#192.168.200.101's password:
\302\226gitea#192.168.200.101: Permission denied (publickey,password).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I have tested the ssh connection in the git bash console with ssh -v gitea#192.168.200.101, and gets
OpenSSH_7.6p1, OpenSSL 1.0.2m 2 Nov 2017
debug1: Reading configuration data /c/Users/admin/.ssh/config
debug1: /c/Users/admin/.ssh/config line 26: Applying options for 192.168.200.101
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.200.101 [192.168.200.101] port 22.
debug1: Connection established.
debug1: identity file C:/Users/admin/.ssh/id_rsa_gitea type 0
debug1: key_load_public: No such file or directory
debug1: identity file C:/Users/admin/.ssh/id_rsa_gitea-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.10 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.200.101:22 as 'gitea'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256#libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64-etm#openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64-etm#openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:YqpRDueradBcei52m4ahex5DgTOwI3QvgJohoZSMzTs
debug1: Host '192.168.200.101' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/admin/.ssh/known_hosts:23
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:DCCnO6UzUiXYhZiNxeaS4SV05fIUZhHK/ZGDPPI6cwc C:/Users/admin/.ssh/id_rsa_gitea
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.200.101 ([192.168.200.101]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00#openssh.com want_reply 0
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
PTY allocation request failed on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow#openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.200.101 closed.
Transferred: sent 3720, received 3624 bytes, in 0.2 seconds
Bytes per second: sent 15126.0, received 14735.7
debug1: Exit status 1
I've tried multiple variations of this, but none of them seem to work. Any ideas?
Update: Push with http works fine. I switched back to ssh and tried to push again, now I get:
Pushing to gitea#192.168.200.101:guanhuizhe/example-repo.git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
During this push the sshd log of the ubuntu server is:
Oct 16 18:08:29 DataStorage2 sshd[29981]: Accepted publickey for gitea from 192.168.200.141 port 14967 ssh2: RSA SHA256:DCCnO6UzUiXYhZiNxeaS4SV05fIUZhHK/ZGDPPI6cwc
Oct 16 18:08:29 DataStorage2 sshd[29981]: pam_unix(sshd:session): session opened for user gitea by (uid=0)
Oct 16 18:08:29 DataStorage2 sshd[30017]: Received disconnect from 192.168.200.141 port 14967:11: disconnected by user
Oct 16 18:08:29 DataStorage2 sshd[30017]: Disconnected from 192.168.200.141 port 14967
Oct 16 18:08:29 DataStorage2 sshd[29981]: pam_unix(sshd:session): session closed for user gitea
Update v2:
The problem is caused by the Ubuntu user I used to run the gitea binary. This user does not have shell. I delete the user and configure a normal user. Everything works fine. Thanks for every one!!
\302\226gitea#192.168.200.101 means the origin in the local git config file .git/config is not gitea, but <START OF GUARDED AREA>gitea.
You can change your Host entry (in ~/.ssh/config) with "gitea" (easier to type than 192.168.200.101)
Test it with:
ssh -Tv gitea
Check also the ~gitea/.ssh/authorized_keys file, to ensure the public key has been added by gitea, and is in a SSH forced command line.
You should see something like:
command="/path/to/gitea --config='/path/to/app.ini' serv key-2",\
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty \
ssh-rsa <yourPublicKey>
If you want to use your ~/.ssh/config entry, then you will need to change your remote:
cd /path/to/repo
git remote set-url origin gitea:<me>/myrepo

why does gitea add ssh and still need a password to log in?

I installed gitea (similar to gitlab)
I added a valid public key in user settings -> SSH KEY
gitea port 3000
run:
ssh -p 22 -Tvv git#***.***.***.***
out:
debug1: Found key in C:\\Users\\client/.ssh/known_hosts:17
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug2: key: C:\\Users\\client/.ssh/id_rsa (000001FBAD96F620)
debug2: key: C:\\Users\\client/.ssh/id_dsa (0000000000000000)
debug2: key: C:\\Users\\client/.ssh/id_ecdsa (0000000000000000)
debug2: key: C:\\Users\\client/.ssh/id_ed25519 (0000000000000000)
debug2: key: C:\\Users\\client/.ssh/id_xmss (0000000000000000)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:W88rhRw****** C:\\Users\\client/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: C:\\Users\\client/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\client/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\client/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\client/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
git#***.***.***.***'s password:
I really don't understand why?
Before that, gitlab was installed,ssh worked normally, but then gitlab was uninstalled andgitea was installed
may I know what is the reason?
in server, run: top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1185 root 20 0 972600 158792 44828 S 0.0 7.7 0:06.96 gitea
Is there any difference between ssh git#***.***.***.*** and ssh root#***.***.***.***?
One reason this problem can come about is that the gitea instance is installed in a docker container on the host. When you shh to your host with the git user, you are intending to ssh into the gitea docker instance, but actually you are just sshing into the server where docker is running. SHH doesn't use domain names, so even if you have a reverse proxy which can see your request for the gitea website on the server, get the gitea website from the gitea docker container, and send it on to your computer, a reverse proxy can't do the same when you ssh in to the server.
The solution is to set up some form of SSH container passthrough. This is documented on the gitea docker installation documentation page (https://docs.gitea.io/en-us/install-with-docker/#ssh-container-passthrough). The gist of it is:
Make a user on the server, outside of the gitea container called 'git'.
Make a key pair that you put in the git user's ~/.ssh folder.
Set the gitea docker volumes to include this git user's ~/.ssh folder as one of the internal docker folders (i.e., share the server's git user's ~/.ssh folder containing the key pair with the gitea docker container's /data/git/.ssh folder
Set the docker user for the gitea container to the same user id as the server's git user
The public key needs to be added to the server's git user's ~/git/.ssh/authorized_keys file (e.g., sudo -u git cat /home/git/.ssh/id_rsa.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys && sudo -u git chmod 600 /home/git/.ssh/authorized_keys)
Make a new command called gitea on the server that is a file containing the following: ssh -p 2222 -o StrictHostKeyChecking=no git#127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $#". This file should be in /usr/local/bin/gitea/ and must be executable (sudo chmod +x /usr/local/bin/gitea)
Take down your docker container and put it back up (from the folder where your gitea docker-compose.yml files is, docker-compose down, then docker-compose up -d)
Test by, at the command prompt on your regular computer: ssh -Tvv git#hostname.com. If it's working you should see a message "Hi there, ! You've successfully authenticated with the key named davidattheready#gmail.com, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user." You can also type the command su git then gitea on the server and you should see no response if it's working, and no error.
Now, once you have gone into the gitea UI and added your key (NOT the same one as you used in steps 2-3 above, but a key on your regular computer) you should be able to run git commands from your non-server computer, pulling/pushing/etc with ssh.
One possible reason SSH would default to asking git password is because:
the SSH key is passphrase-protected
the key was not added to an SSH agent
You can test that by generating a simpler SSH key, for testing, without passphrase:
ssh-keygen -t rsa -m PEM -P ""

In Gitlab CI build, I can't ssh into AWS EC2 by private key

At first, I was trying to use ansible for deployment after gitlab CI built, but it shows "host unreachable" in result.
After some trial and error, I found out the problem is ssh permission denied when ssh by private key into my AWS EC2 instance to deploy.
My .gitlab-ci.yml config is something like this:
.gitlab-ci.yml
image: ansible/ubuntu14.04-ansible:stable
stages:
- deploy
deploy_web:
stage: deploy
script:
- "echo Ansible"
- "echo Environment: ${ENV}"
- "echo TAG: ${TAG}"
- "echo ${VAULT_PASS} > vault_pass.txt"
- "mkdir sshkey"
- "echo ${SSH_KEY_APP} > ./sshkey/app-key.pem"
- "chmod 600 ./sshkey/app-key.pem"
- "export SSH_KEY_DIR=`pwd`/sshkey"
- "export ANSIBLE_HOST_KEY_CHECKING=False"
- "ssh-keyscan foobar.io >> ~/.ssh/known_hosts"
- "ssh -v -i ./sshkey/app-key.pem ubuntu#foobar.io" // for debugging
- "ansible-playbook -i ${ENV} servers.yml --vault-password-file vault_pass.txt -vvvv --tags=${TAG}"
When gitlab CI builds this, it basically gives these ssh error messages:
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Connecting to foobar.io [12.34.56.78] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file ./sshkey/app-key.pem type -1
debug1: identity file ./sshkey/app-key.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA be:b1:53:76:aa:bf:65:ea:b4:1b:7a:8f:cc:7c:2a:79
debug1: Host 'foobar.io' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
Warning: Permanently added the ECDSA host key for IP address '12.34.56.78' to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: ./sshkey/app-key.pem
debug1: key_parse_private2: missing begin marker
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: No more authentication methods to try.
Permission denied (publickey).
Also tried using absolute path:
$ cat /builds/foobar/bar/sshkey/app-key.pem
-----BEGIN RSA PRIVATE KEY-----
...(the key)...
-----END RSA PRIVATE KEY-----
$ ssh -v -i /builds/foobar/bar/sshkey/app-key.pem ubuntu#foobar.io
Permission denied (publickey).
These are what I have tried:
try using shell executor for gitlab CI runner -> failed
run the scripts in a local docker container -> success
ssh into the runner instance manually (not through CI) and run the scripts in shell -> success
ssh into the runner instance manually and run the scripts in docker container -> success
As a conclusion - It only fails when run by gitlab CI, so I wonder if there are any additional configuration I haven't noticed to do things like this...
Many thanks for anyone can help!
The real problem is
When echo-ing a multiline environment variable, quotes are needed.
So basically every line of the key ends with ^M, which shows correctly in gitlab's console but actually unable to be parsed by ssh.
If it fails when run by GilabCI, it means the user used by GitLab CI is not the same as the one used when you ssh in the running instance.
See for instance "AWS SSH connection error: Permission denied (publickey)"
Another thing to check is PermitRootLogin and AllowUsers in /etc/ssh/sshd_config.
This debug1: key_parse_private2: missing begin marker appears even after successful key authorization if your user access restricted.
Check after a manually ssh on the remote machine:
tail -f -n 80 /var/log/auth.log
The OP DarkBtf adds in the comments:
When echo-ing a multiline environment variable, quotes are needed.
So basically every line of the key ends with ^M, which shows correctly in gitlab's console but actually unable to be parsed by ssh.

ssh localhost not working, authenticity of host can't be established

After checking permissions on $HOME and .ssh and running recommended commands am still having trouble getting ssh localhost to work without password. Below is edited history of my commands and output from ssh -vvv localhost. It is failing to load id_rsa and I can not figure out why. Running on Max OSX yosemite 10.10.5
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
I have remote login enabled from preferences.
zak-keirns-imac:~ zak$ ls -l .ssh
total 40
-rw------- 1 zak staff 2252 Dec 13 12:28 authorized_keys
-rw------- 1 zak staff 668 Dec 13 12:28 id_dsa
-rw-r--r-- 1 zak staff 615 Dec 13 12:28 id_dsa.pub
-rw------- 1 zak staff 1679 Dec 13 11:28 id_rsa
-rw-r--r-- 1 zak staff 407 Dec 13 11:28 id_rsa.pub
zak-keirns-imac:~ zak$ ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
Generating public/private dsa key pair.
/Users/zak/.ssh/id_dsa already exists.
Overwrite (y/n)? y
Your identification has been saved in /Users/zak/.ssh/id_dsa.
Your public key has been saved in /Users/zak/.ssh/id_dsa.pub.
zak-keirns-imac:~ zak$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
zak-keirns-imac:~ zak$ ssh -vvv localhost
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/zak/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/zak/.ssh/id_rsa type 1
debug1: identity file /Users/zak/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/zak/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/zak/.ssh/id_dsa type 2
debug1: identity file /Users/zak/.ssh/id_dsa-cert type -1
more output:
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug2: fd 5 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
....
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit: none,zlib#openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5-etm#openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug2: mac_setup: found hmac-md5-etm#openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 508/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 02:f8:78:65:22:75:23:44:c4:82:2a:8f:73:4b:f5:6a
The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 02:f8:78:65:22:75:23:44:c4:82:2a:8f:73:4b:f5:6a.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
debug1: identity file /Users/zak/.ssh/id_rsa type 1
This line tells you that the identity was loaded successfully.
debug3: Could not load "/Users/zak/.ssh/id_rsa" as a RSA1 public key
This is just low-level notice, that the old key type was not recognized. This part is there for some historic reasons and is a bit confusing, but it is NOT an error, just debug3-level note.
The authenticity of the host is something totally different. The keys you generated are used for authentication, but the authenticity is assured by host keys.
If you wan to make sure that you are connecting to right host, copy the public hostkey from server to your ~/.ssh/known_hosts using different secure channel and you will not see this message again.
ssh does not give special status to localhost; it is treated as just another host. Before ssh will connect to a host, it wants to know that it is connecting to the correct host. There is no way for ssh to be able to answer this a priori. You need to verify the host key and confirm it for ssh. At that time, ssh will save it in your known_hosts file. As Jakuje pointed out, you can also copy the key to this file manually.
For localhost, verifying the key is a little easier because it can be found locally in /etc/ssh/ssh_host_rsa_key.pub (on Red Hat-like systems; location will vary on other OS). Once you identify the host key file, you can get its fingerprint with:
ssh-keygen -l -f /path/to/host_key.pub
When you are asked to verify the host key, you can say yes if the fingerprint presented matches the one you computed.
When connecting to a host for the first time, you should determine the host's key fingerprint in advance; this is more challenging with remote hosts. The reality is that most people do not do this, but it is the correct thing to do.

Resources