Hi
i have generate public private key pair using command
ssh-keygen -t rsa -b 2048
and then it made the two keys under the directory
~/.ssh ( in server 1)
one is public key and another one is private ..
i copied public one key onto my second server under the directory
~/.ssh ( in server 2)
in file authorized_keys
and then from server 1 when i entered this command
sftp user2@server2
it asks a passowrd
y it is asking password as i am suppose to automation
What are the permissions on ~/.ssh and the files within? OpenSSH is quite picky about the correct permission, and will refuse to use any of the files if they don't match. Also, did you protect the private key using a password?
Hi
First of all thanks a lot for replying the mail
i have given 777 permission to all the files on server 1 and on server 2 under the directory ~/.ssh
still when i try to connect it asks me a password
---------- Post updated at 06:57 AM ---------- Previous update was at 06:52 AM ----------
and also when i entered this command on server 1
ssh-keygen -t rsa -b 2048
it asks me enter pass phrase i did not give anything i just pressed enter twice
so ideally it should be automated between server 1 and server 2
because i copied the public key in server 2
That's far too permissive, and OpenSSH doesn't like that. ~/.ssh should be 755 max, and authorized_keys should be 600. In no case should the group or other field be set to allow writing.
Current versions of OpenSSH include the ssh-copy-id utility, that copies your identity file and corrects permissions where needed. Give it a try.
hi
i did the same i changed the permission but it is still asking for password 
and yes there is one thing i am seeing here that in the server 1 machine when i do
sftp user2@server2
it do asks for password then if i provide the password it connects and then it creates a file knows_host in the ~/.ssh/ directory in server 1
well , i don't know why it creates this file but it is still asking for password.
please help me regarding this.
Each SSH server has a unique cryptographic fingerprint to lessen the chance of attacks by redirected connections.
Can you give the output of the following command for both servers?
ls -ld ~/.ssh ~/.ssh/id_rsa*
Hi
In server 1 the output is
drwx------ 2 ABC def 512 Feb 25 13:20 def/ABC/.ssh
-rw------- 1 ABC def 883 Feb 25 13:18 def/ABC/.ssh/id_rsa
-rw-r--r-- 1 ABC def 230 Feb 25 13:18 def/ABC/.ssh/id_rsa.pub
and in server 2 it is
$ ls -ld ~/.ssh ~/.ssh/id_rsa*
ABC/ghi/.ssh/id_rsa*: No such file or directory
drwx------ 2 ghi ABC 512 Feb 25 13:22 ABC/ghi/.ssh
In server 2 i have copied public key in "authorized_keys" file
Seems reasonable. Can you give the output of ssh -vv server2 ?
hi
the output is
Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
Usage: ssh [options] host [command]
Options:
-l user Log in using this user name.
-n Redirect input from /dev/null.
-F config Config file (default: ~/.ssh/config).
-A Enable authentication agent forwarding.
-a Disable authentication agent forwarding (default).
-X Enable X11 connection forwarding.
-x Disable X11 connection forwarding (default).
-i file Identity for public key authentication (default: ~/.ssh/identity)
-t Tty; allocate a tty even if command is given.
-T Do not allocate a tty.
-v Verbose; display verbose debugging messages.
Multiple -v increases verbosity.
-V Display version number only.
-q Quiet; don't display any warning messages.
-f Fork into background after authentication.
-e char Set escape character; ``none'' = disable (default: ~).
-c cipher Select encryption algorithm
-m macs Specify MAC algorithms for protocol version 2.
-p port Connect to this port. Server must be on the same port.
-L listen-port:host:port Forward local port to remote address
-R listen-port:host:port Forward remote port to local address
These cause ssh to listen for connections on a port, and
forward them to the other side by connecting to host:port.
-D port Enable dynamic application-level port forwarding.
-C Enable compression.
-N Do not execute a shell or command.
-g Allow remote hosts to connect to forwarded ports.
-1 Force protocol version 1.
-2 Force protocol version 2.
-4 Use IPv4 only.
-6 Use IPv6 only.
-o 'option' Process the option as if it was read from a configuration file.
-s Invoke command (mandatory) as SSH2 subsystem.
-b addr Local IP address.
No, I don't think so. Enter the SSH command as if you want to connect to the remote host, but add -vv (that's a dash followed by 2 lowercase 'V's) in front of the server name (still seperated by a space).
Hi
what i did it on server 1 i typed this command
sftp user2@server2
and the output is
-bash-3.00$ sftp -vv user2@server2
Connecting to server2...
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to server2 port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file ABC/def/.ssh/id_rsa type 1
debug1: identity file ABC/def/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: no match: Sun_SSH_1.1.3
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: cs-CZ,de,de-AT,de-CH,de-DE,fr-CH,hu-HU,pl,pl-PL,cz,hu,sk-SK,i-default
debug2: kex_parse_kexinit: cs-CZ,de,de-AT,de-CH,de-DE,fr-CH,hu-HU,pl,pl-PL,cz,hu,sk-SK,i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: cs-CZ,de,de-AT,de-CH,de-DE,fr-CH,hu-HU,pl,pl-PL,cz,hu,sk-SK,i-default
debug1: Peer sent proposed langtags, stoc: cs-CZ,de,de-AT,de-CH,de-DE,fr-CH,hu-HU,pl,pl-PL,cz,hu,sk-SK,i-default
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 143/256
debug1: bits set: 1566/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'q4de3msys16' is known and matches the RSA host key.
debug1: Found key in /svc/q4de3msys12/dolphin/dolphin6/.ssh/known_hosts:1
debug1: bits set: 1571/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying public key: /svc/q4de3msys12/dolphin/dolphin6/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Trying private key: /svc/q4de3msys12/dolphin/dolphin6/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
there seems to be something wrong with the sftp configuration. might be the keys are not placed at correct locations, may be the permission for the user on the directories where keys are placed.
Hi
Thanks for reply i was waiting for abt one hour for reply :)
Please tell what i should i do i mean i have done two to three times this thing but still it is asking for password.
i have removed the directory .ssh from server 1 and from server 2 but still it is not working
permission is correct
u tell me what info u need i will give it to u but i have to do this.
please help in this
sftp asks for a password only if there is an issue with keys being placed at correct locations and permissions(file or directory). Could you make sure that
Hi
Thanks for reply.
Here is the answers of all questions in my environment
1. The keys should be shared between the client and the server. -- yes keys are there in both client side and server side
2. The .ssh directory should be present in the home directory of the user.--yes, directory is present.
3. The {home_dir}/.ssh/id_dsa.pub or {home_dir}/.ssh/id_rsa.pub file contains the public key. (server side) -- yes both contain public key
4. The client public key key should be placed in the {home_dir}/.ssh/authorized_keys2 file( on the server). -- the public key in the client side is placed under the file authorized_keys not in authorized_keys2 .. should i change it
5. The .ssh directory on both client as well as server should be owned by the user and with 700 permissions. - yes the permission is 700.
6. The files inside the directory should be with 600 permissions.--yes the file permission is 600
ok then could you plz tell me what permission your sftp user has. because its not like that any user can start transmitting files across servers by just creating and sharing keys. The user should have access to do sftp.
iit always ask the password.
sftp won't work without password.
store that user and password into variable and then connect.
if you store in a file then expand that file store the password in a variable.
then it will work.
regards
rajesh
The home directory should also be writable only by the owner:
server~ chmod 775 . && sudo /usr/sbin/sshd -d -p 2222
client~ ssh -p 2222 server
Message on the server side:
...
debug1: trying public key file /home/userid/.ssh/authorized_keys2
Authentication refused: bad ownership or modes for directory /home/userid
...
hi
everyone first of all thanks for repliesss
actually i did all those things but still it is asking password
file permission is correct , don't know why it is asking password
can you please tell me do i need to change the /etc/ssh/sshd_config file also and if yes which variable do i need to set.
please this is very important for me as i have to give this to my company this week only.
please help
I didn't notice a reply to this question. Try copying authorized_keys to authorized_keys2 and see what happens.
There always seems to be confusion as to whether you should be using one or the other of those files.
Andrew