Skip to main content

Hello Experts ;

 

  •  This is regarding creating the Middle Tier setup for IFS Cloud environment in a Remote customer Upgrade.

    - When running the command .\main.ps1 -resource 'KUBERNETES' to install IFS Cloud Middle Tier, getting the error as;

 

 

New-SFTPSession : Channel was closed.
At E:\UPGRADE\ifsroot\utils\common.psm1:48 char:24
+ ... OBAL:sftp = New-SFTPSession -ComputerName $NodeName -Credential $cred ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Renci.SshNet.SftpClient:SftpClient) [New-SFTPSession], SshException
+ FullyQualifiedErrorId : SSH.NewSftpSession

Exception Occurred While Opening Connection with the Linux Box.


 

  • These commands executed successfully.

    .\main.ps1 -resource 'INIT'
    .\main.ps1 -resource 'KEY'

 

  • Error occurs when running : .\main.ps1 -resource 'KUBERNETES'  command.

    - All these servers are remote customer servers

 

  • Could you please support to solve this issue.

 

BR!

/Dilshan

Hi ​@Dilshan Aththanayake,

 

The issue might be of the following as it seems.


Authentication Issues:

If the $keyFilePath(c:\ifsremote\ifsroot\utils\common.psm1) is incorrect or not accessible, the New-SFTPSession command will fail. Make sure that the SSH private key is valid, the file path is correct, and the key has the appropriate permissions.(may be an issue with the extraction of necessary binaries/artifacts used to create the ifsroot directory)


Incorrect Credentials:

Ensure that the $cred(same common.psm1) object holds valid credentials (username and password) or that the key file matches the expected public key on the Linux box.


Network/Connectivity Issues:

Ensure the target machine ($NodeName) is accessible, and there's no firewall or network issue blocking SSH (port 22 by default) or SFTP.


SFTP Module:

Make sure the module providing New-SFTPSession is installed and available. It could be something like Posh-SSH.


File Path for SSH Key:

Ensure that the $keyFilePath is correct and points to an existing private key file. The key file should be in a format supported by SSH(I have seen that this typical key type can have issues with a latest update for Linux, that would  need to be updated for more secured types in 23R1.This is a workaround to be applied if this is a test env with the local.psm1 util file. But not sure this has an impact with the given issue)

 

Regards,

Binuri

​@Dilshan Aththanayake , Try the below steps.
 

  • Add this line in /etc/ssh/sshd_config :- PubkeyAcceptedAlgorithms +ssh-rsa
  • restart the sshd service afterwards and try the kubernetes command from the main.ps1 script.

    if you are trying to install an older version, try out the below steps.

  • Go to ifsroot\utils directory and backup the “local.psm1” file. 

  • Open the file and locate the function Add-KeybasedAuthWithLinuxBox

  • Find following line:- ssh-keygen -b 2048 -t rsa -f "$prvKeyFile" -q -N

  • Change it like below by adding -m PEM option.
    ssh-keygen -b 2048 -t rsa -m PEM -f "$prvKeyFile" -q -N
    (In newer versions the “-m PEM” parameter is included in the file)
  • Once the above change is completed, try the kubernetes command from the main.ps1 script

    Best regards,
    Herath

Hello,

 

There was another origine: the main script is executed on the Windows Management server, the main script seems to put the identity of the current windows user.
 

This means when person A executes the mains.ps1 script, he will be the only one who can execute the script. The person B will have the abouve error. 

I think there is a workaround for allowing more than one windows account executing the script.

 

Terms & ConditionsCookie settings