ECMS - Internal - How PubKey Auth Works for Imaging File Transfers

This document explains how PubKey Auth Works for Imaging File Transfers


How PubKey Auth Works in Theory

  1. When an “account” connects to a remote system for SFTP/SSH access, that remote system can be configured to use UID/PWD or PubKey auth.
  2. If configured for UID/PWD, the SFTP connection must supply them either with the command or in some interactive shell
  3. If configured for PubKey auth, the remote server will already have been configured with the Key(s) for the UID used for the connection, e.g.,
    1. Host PALLICK has an SSH/SFTP server
    2. It is configured to allow connections from a single “account” called xferuser
    3. That account has two Keys associated with it in the server configs, one for “maestro@rigid” and one for “maestro@wingra”
    4. The associated key(s) are of a specific type, either RSA or DSA <– this is important!
    5. When xferuser “attempts” a connection, the server expects a key exchange to occur where the connecting software (e.g., SFTP) provides a key
    6. In this scenario the key is stored in /tws/doit/.ssh/ on the SOURCE system
    7. The actual key file is /tws/doit/.ssh/
    8. The SFTP provided key is then compared to the configured key(s) for xferuser and if matched, the connection is allowed
    9. Now files can be transferred
  4. Where on the SFTP server system an account can read/write files is determined in the SFTP server config
  5. To get the new File Transfer job set up, we had to specify the full path to the key file itself, and not just to the folder where they keys are; e.g., not /tws/doit/.ssh/, but /tws/doit/.ssh/id_rsa
  6. Once that was done and we had data in the remaining required fields, I could save the File Transfer job successfully
  7. Ramifications: it appears we’ll need to know what key type was stored on the remote system to know what key file to specify in the File Transfer job configuration (e.g., PALLICK’s SFTP server config indicated that the key was an RSA key, and that lead to using the id_rsa file rather than the id_dsa file)

How PubKey Auth Works in Practice on PALLICK

  1. Host PALLICK has a user account, xferuser, c:\Users\xferuser
  2. BitVise server has a single uid configured for PubKey auth, xferuser
  3. This BitVise virtual user has the public keys for user maestro from both RIGID [XFER] and WINGRA [LAKE] installed
  4. The new IWS File Transfer SSH job type requires an EXEC capable shell
  5. BitVise configuration options provide access to a local *Nix shell if installed, e.g., bash.exe
  6. MSYS2 provides such: E:\MSYS2\usr\bin\bash.exe
  7. When the File Transfer job connects, it negotiates the trusted connection using the maestro public key
  8. It then EXECS ‘sh’ in the configured shell
  9. If successful, it then execs SFTP for the file transfer
  10. NOTE: the root of the transfer is the root of the WINDOWS account, thus /c/Users/xferuser/...
  11. BitVise does not provide any configuration option to override this root path if use of a full shell is configured!
  12. To gain access to the F:\ volume on PALLICK, use the DOS command mklink to create a symbolic file system link in c:\Users\xferuser to F:\
    CMD.COM #> mklink /D FDrive F:
  13. Use of this symlink will require that the DESTINATION path for all of the current SFTP commands moving file from XFER and WINGRA to PALLICK be modified to add \FDrive\ as the first item in the path