ik gebruik centos 5.9.
na installatie van gitlab via deze linkwerkt ssh niet .
voordat u gitlab ssh correct installeert.
ik gebruik deze server lokaal en andere services zoals elastix en apache, mysql geïnstalleerd op de server.
verschijnt deze fout :
OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.88.23 [192.168.88.23] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x00000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.88.23:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 3111/6144
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:7J6JOe94H9PedNKlx6yG/wMy6ZYC8iB74WdOVGDgY7A
debug1: Host '192.168.88.23' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 3102/6144
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil)),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).
Antwoord 1, autoriteit 100%
Ik had hetzelfde probleem tijdens het gebruik van zwerver. Dus vanaf mijn Mac probeerde ik te ssh naar een zwerverbox (CentOS 7)
Opgelost door de /etc/ssh/sshd_configPasswordAuthentication yeste wijzigen en vervolgens de service opnieuw te starten met sudo systemctl restart sshd
Hopelijk helpt dit.
Antwoord 2, autoriteit 85%
Het instellen van 700 op .ssh en 600 op geautoriseerde_sleutels loste het probleem op.
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
Antwoord 3, autoriteit 28%
Zoals iedereen al heeft gezegd, moet je /etc/ssh/sshd_configbewerken en PasswordAuthentication nowijzigen in PasswordAuthentication yes
Ik kwam dit probleem tegen bij het opzetten van een Vagrant-box – daarom is het logisch om dit te scripten en het automatisch te doen in een shell-provisioner:
sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config;
sudo systemctl restart sshd;
Antwoord 4, autoriteit 24%
Wachtwoordverificatie instellen op ja, is niet de beste manier om te gaan,
is niet zo veilig als het gebruik van privé- en openbare sleutels voor authenticatie!
Zorg er eerst voor dat u de braakliggende machtigingen hebt ingesteld, aan de serverzijde.
Controleer eerst uw thuismap (SERVER SIDE)
[vini@random ~]$ ls -ld ~
drwx------. 3 vini vini 127 Nov 23 15:29 /home/vini
als het niet zo is, ren dan
chmod 0700 /home/your_home
Controleer nu de .ssh-map
[vini@random ~]$ ls -ld /home/vini/.ssh/
drwx------. 2 vini vini 29 Nov 23 15:28 /home/vini/.ssh/
als het er niet zo uitziet, ren dan
chmod 0700 /home/your_home/.ssh
zorg er nu voor dat authorized_keyser zo uitziet
[vini@venon ~]$ ls -ld /home/vini/.ssh/authorized_keys
-rw-------. 1 vini vini 393 Nov 23 15:28 /home/vini/.ssh/authorized_keys
of ren gewoon
chmod 0600 /home/your_home/.ssh/authorized_keys
Ga daarna naar /etc/ssh/sshd_config
Voor de beste beveiligingsset
PermitRootLogin no
PubkeyAuthentication yes
bewaar als yesvoor testdoeleinden
PasswordAuthentication yes
Zorg ervoor dat
ChallengeResponseAuthentication no
Reageer op die regels voor GSSAPI
# #GSSAPIAuthentication yes
# #GSSAPICleanupCredentials no
Zorg ervoor dat dit is ingesteld op UsePAM yes
UsePAM yes
start sshd-service nu opnieuw
systemctl restart sshd
aan de klantzijde
cd /home/your_home/.ssh
nieuwe sleutels genereren; het instellen van een wachtwoord is optioneel, maar is een goed idee
ssh-keygen -t rsa -b 2048
kopieer de pub-sleutel naar uw server
ssh-copy-id -i id_rsa.pub user_name@server_ip
start ssh agent
eval $(ssh-agent)
ssh-add /home/user/.ssh/your_private_key
nu ben je klaar om te gaan!
ssh user_name@server_ip
als alles goed werkt
maak een back-up van uw privésleutel en weiger vervolgens PasswordAuthentication
PasswordAuthentication no
Herstart je server
iedereen die probeert naar uw server te ssh-en, zonder uw sleutels, zou dit moeten krijgen
vini@random: Permission denied (publickey).
Houd scriptkids weg bij uw bedrijf, en veel succes
Antwoord 5, autoriteit 9%
Zorg ervoor dat de volgende wijzigingen niet worden becommentarieerd, wat ik deed en kreeg succes in centos7
vi /etc/ssh/sshd_config
1.PubkeyAuthentication yes
2.PasswordAuthentication yes
3.GSSAPIKeyExchange no
4.GSSAPICleanupCredentials no
systemctl restart sshd
ssh-keygen
chmod 777 /root/.ssh/id_rsa.pub
ssh-copy-id -i /root/.ssh/id_rsa.pub user@ipaddress
allemaal bedankt en veel succes
Antwoord 6, autoriteit 7%
Volgens de regel debug1: Authentications that can continue: publickey,gssapi-with-mic, ssh wachtwoord authenticatie is uitgeschakeld en blijkbaar gebruikt u geen public key authenticatie.
Log in op uw server via de console en open het bestand /etc/ssh/sshd_configmet een editor met rootgebruiker en zoek naar regel PasswordAuthenticationen stel de waarde in op yes en herstart eindelijk de sshd-service.
Antwoord 7, autoriteit 4%
In Centos 7
Fout: publickey,gssapi-keyex,gssapi-with-mic
Antwoord: Root-toegang tot vi /etc/ssh/sshd_config en verander de PasswordAuthentication ( nee ) in yes.
2 . Start de sshd-services opnieuw
root> systemctl herstart sshd.service
- Log in op lokale id via stopverf zonder sleutel.
Antwoord 8, autoriteit 4%
Veel dingen geprobeerd, het heeft niet geholpen.
Het krijgt op een eenvoudige manier toegang:
eval $(ssh-agent) > /dev/null
killall ssh-agent
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa
Houd er rekening mee dat aan het einde van de ssh-add -L-uitvoer geen pad naar de sleutel mag staan, maar uw e-mailadres.
Antwoord 9, autoriteit 4%
Ik probeer
rm ~/.ssh/id_rsa.pub
dan werkt het!
Antwoord 10, autoriteit 4%
Niemand heeft dit vermeld in bovenstaande antwoorden, dus ik vermeld het.
Deze fout kan ook optreden als u zich in de verkeerde map bevindt of als het pad van uw pem-bestand niet correct is. Ik had een soortgelijk probleem en ontdekte dat mijn pem-bestand er niet was van waaruit ik het ssh-commando uitvoer
cd KeyPair
ssh -i Keypair.pem [email protected]
Antwoord 11, autoriteit 2%
Ik had hetzelfde probleem. In mijn geval laadt macOS mijn SSH-sleutels niet, maar ik repareer het met:
ssh-add <SSH private key>
ssh-add <SSH public key>
Ik kon geen verbinding maken met een Droplet op DigitalOcean, maar de volgende opdrachten werken voor mij.
Je kunt naar het forum gaan hier.
Antwoord 12
opgelost door GSSAPIAuthentication in te stellen op nee in /etc/ssh/sshd_config
Antwoord 13
Misschien moet je de openbare sleutel toewijzen aan de authorized_keys, de eenvoudige manier om dit te doen is door ssh-copy-id -i your-pub-key-file user@dest.
Antwoord 14
En ik denk dat dit de oorzaak van het geposte probleem zal ophelderen, eigenlijk is dit een bug van pssh zelf (bevat in “askpass-client.py”). Het is het lib-bestand van pssh. En er is een gedocumenteerd probleem voor -A case:
https://code.google.com/archive/p /parallel-ssh/issues/80
Er zijn twee mogelijke oplossingen om de versie van pssh die deze bug bevat te gebruiken voor het geval je gedwongen bent een wachtwoordzin te gebruiken voor toegang tot de privésleutel:
- Corrigeer uw “askpass-client.py” zoals beschreven in de link die eerder in mijn bericht is vermeld.
- Uw favoriete pasbewaarder gebruiken.
Bedankt voor de aandacht, ik hoop dat het helpt!
Antwoord 15
Eerst moet een wachtwoord-login worden ingesteld op de externe machine
- Maak eerst een wachtwoord login
je moet inloggen met een wachtwoord inschakelen door de eigenschap ie) PasswordAuthentication yesin het sshd_config-bestand in te schakelen. Start vervolgens de sshd-service opnieuw en kopieer de pub-sleutel naar de externe server (aws ec2 in mijn geval), sleutel wordt zonder fouten gekopieerd
- Zonder wachtwoord inloggen werkt alleen als en alleen als wachtwoord login is gemaakt
- kopieer de inhoud van de pubsleutel naar geautoriseerde sleutels, cat xxx.pub >> ~/.ssh/authorized_keys
Antwoord 16
Dit kan gebeuren als u de juiste id_rsa-sleutel mist die is ingesteld in Authorized_keys voor een AWS-instantie.
Exacte fout die ik kreeg (dit artikel kwam naar voren toen ik de fout googelde):
[email protected]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Opmerking: als je veel sleutels hebt, moet je de sleutel opgeven op de ssh-opdrachtregel of anders toevoegen aan je ssh-agentsleutels (zie ssh-add -l). Alleen de eerste 6 sleutels van ssh-agent werken mogelijk – de standaard sshd MaxAuthTries-configuratiewaarde is 6.
Antwoord 17
Ik hoop dat dit iemand zal helpen. Het probleem dat ik tegenkwam, is dat ik volledig de verkeerde sleutel gebruikte met het IP-adres. Zorg ervoor dat u de juiste sleutel voor het juiste IP gebruikt
Antwoord 18
Voor mij is het een volkomen vergissing, iemand kopieert en plakt de sleutel in dezelfde rij met een andere sleutel, na ze in twee verschillende regels te hebben gescheiden, dan werkt het weer, dus controleer of uw Authorized_key-bestand soortgelijke fouten bevat!
Antwoord 19
Ik had hetzelfde probleem Toestemming geweigerd (publickey, gssapi-keyex, gssapi-with-mic) eerder.
Ik moest naar /etc/ssh/sshd_config om de gebruiker gebruiker toe te voegen aan de sectie AllowUsers, en startte vervolgens de sshd-service opnieuw.
Antwoord 20
Laat me met je delen hoe ik het heb gedaan en ik weet zeker dat je een goed antwoord zult vinden hier.
Zorg ervoor dat het volgende
Stap 1. U heeft
Public DNS (IPv4) from awsbijv. ec2-IPV4.us-east-2.compute.amazonaws.com
Stap 2. U onthoudt waar uw
your_secret_key_is.pemHet is bijvoorbeeld beter om het ver van de root van de bekende mappen zoals Downloads, Desktop of Documents te houden
Stap 3 Open terminal en voeg het commando
sudo ssh -v -i path-to-key.pem ec2-user@hosttoe
ec2-gebruikeris belangrijk omdat het voor sommige linux-servers de gebruikersnaam is
sudohet heeft toestemming nodig om uit te voeren
hostHet is Amazon Public DNS (IPv4) (kopieer stap 1)
Vind meer informatie hier
Antwoord 21
Ik weet dat dit een oude vraag is, maar ik dacht laat ik mijn oplossing in de pot doen.
Ik kreeg dezelfde foutmelding toen ik probeerde verbinding te maken met Amazon Linux vanuit Ubuntu. De oplossing was om dit eenvoudig te veranderen:
ssh-add -c <key_location>.pem
naar dit:
ssh-add "<key_location>.pem"
… een vrij simpele verandering heeft me geholpen.