I would like to configure on a linux client ssh to use TACACS+ server.
To do so I configure sshd on pam.d directory to auth using pam_tacplus.so.
The problem
Unless I have the user LOCALLY declared on the linux machine - I can't authenticate it.
This is quite normal as I must have a user on a linux session.
The question(s)
Do I HAVE TO declare the user locally when the 'device' is a linux machine? (I know that on network devices I don't).
If I don't have to, then how do I grab the user's permissions, environment, etc from the tacacs server?
Thanks.
TACACS+ doesn't natively provide sufficient details to fulfill the "name service" needs of Linux systems. It is this functionality of glibc that is responsible for providing the system with details for the user's 'passwd' entry, for example.
It is would be possible to achieve this with a custom NSS module, which could pull the correct details from the TACACS+ backend. This would be similar to what is done for LDAP-based authentication, where a user is given additional attribute that represent items like UID, GID, HOME, SHELL, etc.
I am not aware if there is an open source module that provides this functionality today, but it possible.
Related
I'm using WSL in an exclusively windows environment because of a number of tools that are only really available for Linux. I often connect to DBs programmatically and would like to be able to do that without specifying my login information. For example in Python through Windows I could do this:
import pymssql
con = pymssql.connect(server, port)
And that connection would go through without my having to specify any credentials because my AD account has access to the server, and pymssql will use windows auth when no credentials are specified.
In python running on WSL however that doesn't work, and so to make the same connection I would have to additionally pass the user and password parameters.
Is there any way to make WSL inherit windows authentication when running Linux processes?
I got you Fam!
Here is the solution : http://michaeljw.com/blog/post/keyring-r-python-windows/
Here is the Sauce:
Use the Windows Credential Manager to store the creds you want to use
https://support.microsoft.com/en-us/windows/accessing-credential-manager-1b5c916a-6a16-889f-8581-fc16e8165ac0
Here is the command for accessing the credential manager in Python:
keyring.get_password(u"[Domain or URI]", u"[username]")
As long as the user is in the cred manager, you should be able to use that command to variablize creds. You will probably have to play with it a bit to get it right, but it will work. Be sure to read the linked articles.
Enjoy
Since version 5.50 the Bitvise SSH Server allows connected client to authenticate to Windows user account without providing this user's Windows password. See here: https://www.bitvise.com/ssh-server-version-history
I've checked it myself - it does indeed.
My question is of pure curiosity: what kind of sorcery is this? Is there any WinAPI that allows such thing or is this some kind of clever hack? I always thought it is impossible to impersonate as other user without a password (as even when configuring Windows service or scheduled task to "run as user" it is neccessary to provide one).
IIRC, the SSH server in Cygwin does the same thing.
If you have the appropriate privileges you can create an access token with ZwCreateToken, no password required. Such a token has some limitations. For example, you can't access network resources without a password and some encrypted material isn't accessible.
There's an explanation and some sample code here.
Since version 5.50, Bitvise SSH Server comes with a Windows authentication package. An authentication package can enhance the Windows logon process in custom ways. When the SSH server needs to log you in, but does not have a password (e.g. because you logged in with a public key), it calls the authentication package to construct a logon token which closely resembles the logon token that would have been created by Windows. As arx has noted, a session created this way does not contain your authentication credentials, so side effects are that you can't access things like network resources and EFS.
Maybe not the best worded question, but hopefully it's a straightforward problem.
The scenario is SSHing from a personal account on box A to a generic account on box B. The script running on box B needs to capture the personal account name for logging purposes. Is there any way of capturing this, either via SSH itself or some information captured by the shell? We are using ssh2 (Reflections), and KornShell (ksh) on Solaris.
If you have full control of the client machine, you can deploy identd to get the username.
Full procedure to get name from script:
Walk up process tree, find sshd
Walk netstat -p to find the remote IP and port.
Connect to client on port 113 and ask.
You may have to disable privilege separation for this to work as-is; however it should be trivial to modify to work w/o it.
You can't log the remote username reliably
You can log the IP of the connection (see the SSH_CONNECTION variable)
You could have a standard where they use an alias for ssh that logs the remote username as part of the login process, or where they store their username in a .ssh/environment file (but allowing environments to be set may require ssh/sshd config changes).
alias sshblah='ssh blah "REMOTEUSER=$USER; bash'
(Except that doesn't work, and I haven't tried to figure out why - and it would be different if you use tcsh, etc).
You can use environment passing in this manner, and select which variables you allow to be set. You'd have to get the users to set some alternate to $USER, like $REMOTE_USER=$USER, and then allow $REMOTE_USER to pass through. And you're trusting they don't set it incorrectly, or forget to set it (you can handle that case with a little annoyance by modifying this mechanism).
Note that you almost have to trust the client connecting to tell you who the user is - you can make it hard/annoying to spoof the username, but unless you use per-user certificates instead of a generic login/password they all know, you can't verify who connected.
What is the best way to send a password to a Windows Service? Our application needs a password in order to start. I don't care that services are "normally" supposed to run without user interaction. Its good enough for us that an operator can start the application and then log off.
On a unix system, I would just echo the password over stdin but the service has no stdin.
Currently, we use the DPAPI to just store the password using CryptProtectData. While this, works, it presents other problems that are beginning to become troublesome.
I'm guessing that I'll need to use some form of IPC between the service and the application that is sending the password but I'm not sure which method is appropriate, if any.
Thanks
Two main options:
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
Thanks for responding Rowland.
You could listen on a socket on
startup and wait for the required
password to be supplied (maybe embed
an SSH server in there, so that the
password cannot be snooped over the
wire)
I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?
My preferred option would be to read
the password from a configuration file
(that can be secured to the minimum
readership) or registry setting
(again, sufficiently secure such that
only your service and administrators
can read/change it)
We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.
You can use kerberos mutual authentication. There are few options and examples there.
But just wondering. On a compromised machine, There may be a key logger. So typing the password is never secure if you want to maintain security in this environment. The same problem exist afaik for unix terminals.
DPAPI in UserMode is really the best option, and storing the encrypted data in a protected location, e.g. registry key with limited ACL.
What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...
What exactly were the problems that
are beginning to be troublesome? Maybe
we can just solve those...
Currently, the application runs as the Local System account.
Our application stores a number of credentials in an encrypted file and uses the DPAPI (in UserMode) for the encryption.
Thus, when the application is installed, the installer is run as the Local System account. We also have a set of tools that ship with the application, some of which need access to this encrypted file and thus, they too need to run as the Local System account.
By the time the application is installed and started, we're heavily dependent on that account.
We're running into problems because one of our users wants to use the application to access a shared network drive. The Local System account has no such privileges and we can't simply run our service as a different user because our encrypted information is protected under the Local System Account.
We've tried to avoid the process of setting up a user account just for our application because it is installed across many different customers and environments, all of whom have wildly different security policies.
You can access a remote drive from a service running under system account. However, you will need to have credentials & share information to connect to the remote machine. You can use the API wnetaddconnection to gain access. Probably your encrypted file can store this credential as well.
I've had a FTP server (Mac OS X, but not the server version) set up for a while where the users are virtual, i.e. they are not actual user accounts in the server's OS, but accounts handled by the FTP server software -- to the OS they all look like the ftp user account. I'd like to retire the FTP server software and go SFTP instead.
Is there a way to set up SFTP/SSH so that I can create virtual users and at the same time sandbox them?
The reason I want virtual users is because I add and remove accounts from time to time, and doing that with proper user accounts tend to get messy, and I don't know of a good way to sandbox them. There's always some files left and each user has their own user directory (with a lot of files only relevant if they would actually log on to the machine when sitting in front of it), which is quarantined when the account is removed, so you have to remove it by hand yourself, and so on.
The usual generic Unix answer to this is 'PAM'. If you want plain old OpenSSH SSHD to handle your SFTP, you need something plugged in to SSHD's PAM stack (/etc/pam.d/sshd) that does what you need and leaves out what you don't need. This might be a general-purpose directory server (probably LDAP) that maps all your virtual users to one home directory and gives them a restricted or scponly kind of shell.
If you want to look at FTP servers that can also do FTP-ssl (which is not the same as SFTP), good ftp servers like Pure-ftpd or vsftp will do that. FTP-ssl servers have simpler virtual user support.
http://www.bsdguides.org/guides/freebsd/networking/pure-ftpd_virtual_users.php
If you're open to commercial products, VShell Server from Van Dyke Software is available on Unix/Linux/Windows, supports virtual users (multiple backends) with SSH and SFTP protocols:
VShell Server
JSCAPE SFTP Server is a commercial, cross-platform server that does what you want.
http://www.jscape.com/
I know, sounds like I work for them, but I don't :)
There is sftpgo which supports virtual users and much more.