You are not logged in.
Pages: 1
Topic closed
I've been using a lot of SSH for some time, but I am really tired of typing password all the time, so I wanted to start using SSH keys together with ssh-agent to simplify the process.
It isn't as easy as that though. It doesn't work :<
Let's say I'm sitting on computer A, and I want to connect to my server B. I am supposed to run the keygen on computer A and copy the .pub-file over to my server B:
ssh-keygen -t dsa
scp ~/.ssh/id_dsa.pub maister@<ip>:
ssh maister@<ip>
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
rm ~/id_dsa.pub
exit
Assuming that what I did was correct here, and that I configured the local /etc/ssh/ssh_config and the remote /etc/ssh/sshd_config correctly, I should have to try the new passphrase for the DSA key next time I log in.
I always get greeted with the standard password authentication I've been using all along. I've tried a lot in both ssh-config files, and I have no idea why it shouldn't work.
Local ssh_config:
Host *
Port 666 #evul :p
Protocol 2
PubkeyAuthentication yes
PasswordAuthentication yes
IdentityFile ~/.ssh/id_dsa
Remote sshd_config:
AllowUsers lulz haiu wat maister
Port 666
ListenAddress 0.0.0.0
Protocol 2
LoginGraceTime 1m
PermitRootLogin no
MaxAuthTries 3
MaxSessions 5
StrictModes yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
Subsystem sftp /usr/lib/ssh/sftp-server
I guess I should include the verbose output when I try to connect:
ssh 10.0.0.66 -v
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.0.0.66 [10.0.0.66] port 666.
debug1: Connection established.
debug1: identity file /home/maister/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[10.0.0.66]:666' is known and matches the RSA host key.
debug1: Found key in /home/maister/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/maister/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
Last edited by Themaister (2009-10-03 22:43:17)
Offline
Do you specify the private key when connecting?
ssh -i </path/to/private/key> user@server
Alternativly you can also use ssh-agent of course.
Offline
Found something very interesting in ssh-copy-id's man page:
It also changes the permissions of the remote user's home, ~/.ssh, and
~/.ssh/authorized_keys to remove group writability (which would other‐
wise prevent you from logging in, if the remote sshd has StrictModes
set in its configuration).
So more permissive permissions are likely causing the public key authentication to fail in your case.
Offline
Found something very interesting in ssh-copy-id's man page:
It also changes the permissions of the remote user's home, ~/.ssh, and
~/.ssh/authorized_keys to remove group writability (which would other‐
wise prevent you from logging in, if the remote sshd has StrictModes
set in its configuration).So more permissive permissions are likely causing the public key authentication to fail in your case.
That happened to me once but it actually says that the key's permissions are too open. It doesn't fail silently.
Might be a different problem, I dunno
Offline
try this in your sshd_config
ChallengeResponseAuthentication no
Offline
I've tried all your suggestions over, and I think it's something with the keys. I don't know why it should happen, but:
Super verbose output:
ssh 10.0.0.66 -vvv
debug3: Not a RSA1 key file /home/maister/.ssh/id_dsa. # <----- ?!?
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
Offline
I believe that RSA1 error is normal. They combined the key checking so you don't have to specify the format of the key file. openssh just checks rsa v1, rsa v2, and dsa v2 for all keys.
maybe try forcing protocol 2 with "ssh -2 user@host"
maybe try deleting ~/.ssh/known_hosts on the client side
check permissions on ~/.ssh for both machines. It should be 700 aka drwx------
the client's modes ~/.ssh/id_dsa should be 600 aka -rw-------
double check the server side ~/.ssh/authorized_keys is spelled correctly, mine is mode 644 aka -rw-r--r-
Try starting the server in debug mode ... "sshd -d -p 666" and then try to connect.
I see you're running sshd on an alternate port. You are starting it as root right? If not, you'll have to ensure the server can read the authorized_keys.
Also, if windows is involved, you'll want to ensure you do a binary transfer of id_dsa.pub
Offline
I finally figured it out. I had wrong permissions on my home directory on the server.
server$ chmod go-w ~/
server$ chmod 700 ~/.ssh
server$ chmod 600 ~/.ssh/authorized_keys
Fixed my problem ... <_< So much for just having group write access for ~/
OpenSSH is seriously strict on this, but I guess that's a positive thing.
Last edited by Themaister (2009-10-03 21:48:51)
Offline
Hello all,
I know it's been a while and issue been fixed, but wanted to share problem I just had and actually because if this issue I found this thread.
So I was trying to migrate few website using Plesk Migrator and had issues when ssh connection was hanging up with permission denied error.
As it turns out, because I have upgraded openssh to version 7 a while ago it's configuration disallowing ssh-dss type keys from been valid by default: https://www.gentoo.org/support/news-ite … -keys.html
So as suggested in the article, adding 'PubkeyAcceptedKeyTypes=+ssh-dss' to ~/.ssh/config helps.
Hope it will help someone with similar issues.
Offline
We had a similar news article here: https://www.archlinux.org/news/openssh- … -dss-keys/
Please don't necrobump.
Closing.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Pages: 1
Topic closed