Skip navigation.

Vikram Das

Syndicate content
Blog dedicated to Oracle Applications (E-Business Suite) Technology; covers Apps Architecture, Administration and third party bolt-ons to Apps
Updated: 16 hours 55 min ago

sftp failure due to newline character difference between windows and unix.

17 hours 10 min ago
Recently I spent almost a full day struggling to make out, why an sftp connection would not work without password, after setting up ssh equivalence.  The keys were correct, the permissions on the directories were correct.  The authorized_keys file looked ok.  I copied the authorized_keys file of another account that was working fine.  When I replaced the authorized_keys after taking backup of original authorized_keys, it started working.  So then I proceeded to check the contents in a hex editor

On the left side you have the authorized_keys file created in Windows.
On the right side you have the same authorized_keys file created in Unix.

If you notice the ends of the lines in the Windows file it shows CR LF, where as unix shows LF.

This difference is well described in the wikipedia article on newline character.

The one mistake I had done this time was create the authorized_keys file in Windows notepad, as I was teaching a Developer how to create authorized_keys file.  Once I used vi on unix to create the authorized_keys file and pasted the same ssh key, sftp started working without prompting for password.  I know that Windows/DOS and Unix have different newline characters.  However, I was not able to apply that knowledge, till I compared the files in hex editor.

Whenever, a techie is able to get to the root cause of a problem, a deep sense of satisfaction is experienced.  I am glad I got the opportunity to troubleshoot and fix the issue by getting to the root cause of the issue.
Categories: APPS Blogs

Copycat blog

Tue, 2015-09-15 02:50
While doing a google search today I noticed that there is another blog that has copied all content from my blog and posted it as their own content and even kept a similar sounding name: .  I have made a DMCA complaint to google about this.  The google team asked me to provide a list of URLs.  I had to go through the copycat's whole blog and create a spreadsheet with two columns. One column with URL of my original post and second column with the URL of the copycat's blog.  There were 498 entries.  I patiently did it and sent the spreadsheet to google team and got a reply within 2 hours:

In accordance with the Digital Millennium Copyright Act, we have completed processing your infringement notice. We are in the process of disabling access to the content in question at the following URL(s):

The content will be removed shortly.
The Google Team 
Categories: APPS Blogs

Server refused public-key signature despite accepting key!

Mon, 2015-06-22 11:23
A new SFTP connection was not working, even though everything looked fine:

1. Permissions were correct on directories:
chmod go-w $HOME/
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/authorized_keys
chmod 600 $HOME/.ssh/id_rsa
chmod 644 $HOME/.ssh/
chmod 644 $HOME/.ssh/known_hosts

2. Keys were correctly placed
However, it still asked for password, whenever SFTP connection was done:
Using username "sftpuser".Authenticating with public key "rsa-key-20150214"Server refused public-key signature despite accepting key!Using keyboard-interactive authentication.Password:
I tried various things, none worked and I eventually went back to my notes for SFTP troubleshooting:
1. Correct Permissionschmod go-w $HOME/chmod 700 $HOME/.sshchmod 600 $HOME/.ssh/authorized_keyschmod 600 $HOME/.ssh/id_rsachmod 644 $HOME/.ssh/id_rsa.pubchmod 644 $HOME/.ssh/known_hosts
2. Make sure the owner:group on the directories and files is correct:
ls -ld  $HOME/ls -ld  $HOME/.sshls -ltr $HOME/.ssh
3. Login as root
chown user:group $HOME chown user:group $HOME/.sshchown user:group $HOME/.ssh/authorized_keyschown user:group $HOME/.ssh/id_rsachown user:group $HOME/.ssh/id_rsa.pubchown user:group $HOME/.ssh/known_hosts
4. Check for user entries in /etc/passwd and /etc/shadow
5. grep user /etc/shadow
When I did the 5th step, I found that /etc/shadow entry for the user didn't exist.  So I did these steps:
chmod 600 /etc/shadowvi /etc/shadowInsert this new line at the endsftpuser:UP:::::::Save Filechmod 400 /etc/shadow
It started working after that.
Categories: APPS Blogs