salt-ssh hardcodes SSH port 22 as default

[bebehei]

I'm running my ssh server on my systems on a Port != 22.

So while I configure the system correct in ~/.ssh/config, I can ssh just by ssh <host>.

So the ideal case would be, that I use the salt-roster only for translating the Salt ID to the ssh hostname:

saltmaster:
  host: some.host.company.com

But the saltroster sets a default of Port 22 if None is given. Therefore I have to give always the port number, too:

saltmaster:
  host: some.host.company.com
  port: 6152

This leads to doubled information.
Also: The port 22 is default by SSH. Why do we have to set the default Port of salt-ssh to 22, if SSH has it already set?

[bebehei]

I believe the fix would be just to change salt/config/schemas/ssh.py Line 45 as other parts just check before using the port if it is available.

[jfindlay]

@bebehei, thanks for the report. What version of salt are you using?

[bebehei]

salt-ssh --versions-report
Salt Version:
           Salt: 2015.8.3

Dependency Versions:
         Jinja2: 2.8
       M2Crypto: 0.21.1
           Mako: 1.0.3
         PyYAML: 3.11
          PyZMQ: 15.1.0
         Python: 2.7.11 (default, Dec  6 2015, 15:43:46)
           RAET: Not Installed
        Tornado: 4.3
            ZMQ: 4.1.3
           cffi: 1.4.2
       cherrypy: Not Installed
       dateutil: 2.4.2
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: 1.2.5
      pycparser: 2.14
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: Not Installed
        timelib: Not Installed

System Versions:
           dist:   
        machine: x86_64
        release: 4.3.3-2-ARCH

[jfindlay]

It seems reasonable that salt-ssh could check the contextual ssh settings to try to determine the port if it is nonstandard.

[bebehei]

salt-ssh sets options for SSH via command line (-o <optionName>=<value>). These values override the ones set in ~/.ssh/config.

$ cat roster
...
vm0:
  host: vm0.host.b3be.de
  #port: 6152
...
$ salt-ssh -l trace vm0 test.ping
....
[TRACE   ] Terminal Command: /bin/sh -c ssh vm0  -o KbdInteractiveAuthentication=no -o PasswordAuthentication=no -o GSSAPIAuthentication=no -o ConnectTimeout=65 -o Port=22 -o IdentityFile=/home/bebe/code/salt-config-bene/.salt_pki/ssh/salt-ssh.rsa -o User=root  /bin/sh
....
vm0:
    ssh: connect to host vm0.host.b3be.de port 22: Connection refused

The SSH Protocol defines Port 22 as the default. There is no need to specify -o Port=22. Then it would take the options from the config-file. This is just a problem of setting things twice.

[basepi]

Pretty sure there's already an issue open for using the .ssh/config and whatnot, but I'm having a bear of a time finding it, so it must have been part of the discussion on another issue....

Anyway, this is something we want to do at some point.

[bebehei]

I'd pledge for _not_ using the ssh-config and parsing it. Let this please be the job of ssh.

Parsing the ssh-config is a real PITA. There are so many tarpits. For example you have to parse the config two times, when CanonicalizeDomains is set, support Match clauses, etc..

Additionally by parsing .ssh/config manually, you decline any good feature provided by ssh. As I said, I believe the error is

[bebehei]

... in the options Parser salt/config/schemas/ssh.py Line 45. There is a default specified, which is not neccessary. Sadly I'm not able to test this.

[basepi]

You're probably correct.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.