Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya Linux App Server - Unable to access WinSCP using root

J8uppy95

Systems Engineer
Joined
Aug 5, 2024
Messages
8
Location
GB
Hello, I'm wondering if anybody else has encountered the same issue.

Basically, we've installed a voicemail pro new app server on version 11.1.1.1.0 build 18. Upon ignition, it asks you to set a root password/administrator password/system password. The root password and administrator password are the same and I know they're 100% correct. When using WinSCP to move the WAVs/Names/Greetings/Accounts across, it's not letting me log in using root - I get an access denied error. However, if I login using Administrator it works but I'm unable to move the WAVs/Names/Greetings/Accounts due to permissions. The WAVs upload into the custom prompts folder which I can deal with.

I've had a look around but I can't find a definitive answer on why it won't let me login as root. If anybody has experienced this, please can you provide a fix :)? A few people have said the root username needs enabling but I can't figure out how to enable it.

Thank you.
 
Just guessing but if you log in as root on the terminal itself. Look at the SSH config. You will likely find login as root is disallowed. You will need to allow it and then restart the ssh service. This is normal for most new distros of Linux which seek to limit roots direct access to the system. The newer preferred method of access is to use the Admin account. Which of course you see doesn't work very well at times.

The path to the SSH config might be /etc/SSH/ssh_config

You may need to do a search on your version of Linux.
 
Just guessing but if you log in as root on the terminal itself. Look at the SSH config. You will likely find login as root is disallowed. You will need to allow it and then restart the ssh service. This is normal for most new distros of Linux which seek to limit roots direct access to the system. The newer preferred method of access is to use the Admin account. Which of course you see doesn't work very well at times.

The path to the SSH config might be /etc/SSH/ssh_config

You may need to do a search on your version of Linux.
Hello, thank you for responding. I've found the ssh_config file and can open it via text editor - The issue is I can't see anything to do with the root being disabled (info below FYI)

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Protocol 2
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
#
# Uncomment this if you want to use .local domain
# Host *.local
# CheckHostIP no


Thanks
 
This is from a FAQ I wrote that got lost when they updated Tek-Tips. This was specific to R11.1. From the list you posted it might be the PermitLocalCommand no but I do know these instructions did work for that version of app server.

At the linux prompt login as root.
Enter: sudo vi /etc/ssh/sshd_config
Press ‘I’ to enter into insert mode and modify the entry.
Change PermitRootLogin no to PermitRootLogin yes
Press esc key to exit insert.
Type :wq to write and exit the editor.
At the command line type ‘service sshd restart’ to restart the service.
This will allow full access to the server file structure through WinSCP.
It is best practice to change this back to ‘no’ when the process is complete.
Do this procedure to both servers.
 
This is from a FAQ I wrote that got lost when they updated Tek-Tips. This was specific to R11.1. From the list you posted it might be the PermitLocalCommand no but I do know these instructions did work for that version of app server.

At the linux prompt login as root.
Enter: sudo vi /etc/ssh/sshd_config
Press ‘I’ to enter into insert mode and modify the entry.
Change PermitRootLogin no to PermitRootLogin yes
Press esc key to exit insert.
Type :wq to write and exit the editor.
At the command line type ‘service sshd restart’ to restart the service.
This will allow full access to the server file structure through WinSCP.
It is best practice to change this back to ‘no’ when the process is complete.
Do this procedure to both servers.
Hello, thank you for your response. I've finally figured this out, instructions below (slightly different to the ones you provided)

# nano/etc/ssh/sshd_config

change PermitRootLogin from no to yes

Press CTRL X then Y = save on exit

Enter # systemctl restart sshd and enter

This then allowed me to login to WinSCP using root!

Thanks for your help.
 
Yep that was the permission I remember.

PermitRootLogin

I have had to set that on a number of servers I worked on.
 
You could try this:

setfacl -R -m u:username:rwx /path/to/directory

Allowing root to login directly is a security risk.
 
The security risk is why I recommend setting it back to no when you are done since typically you only need to do the file move when you are migrating the files for an install and will be maintaining them through VMPro.
 

Part and Inventory Search

Sponsor

Back
Top